Оборудование Hybrid Simulation Lab. На фото показана панель управления SDS 9300, который, совместно с несколькими аналоговыми компьютерами, отрабатывал симуляции командного модуля и лунного модуля.

За годы до появления Apollo 11, когда разрабатывалась система управления, о встроенном программном обеспечении думали как о чём-то таком, что можно сделать в последнюю очередь: «Хэл это сделает» — так они говорили. На самом деле этим занимались десятки людей, и сотни людей вспомогательного персонала, но Хэлу Лейнингу (Hal Laning) сначала пришлось разбираться, как организовать многочисленные функции ПО, чтобы они выполнялись практически одновременно в реальном времени на бортовом компьютере космического аппарата, имеющем ограниченные размер и быстродействие.

Архитектура Хэла позволила избежать подводных камней, свойственных операционной системе, в которой вычисления должны быть четко разделены между временными отрезками. Такие системы довольно трудны в реализации, потому что задачи могут меняться произвольно. Когда в процессе разработки задачи добавляются или меняются, может потребоваться изменение в планировании задач. Самое плохое, что существовавшая операционная система бортового компьютера очень хрупкая, в том смысле, что она полностью выходит из строя, если задача занимает больше времени, чем было выделено.

Вместо этого Лейнинг разработал систему, в которой программные функции распределяются в виде «задач», которые могут быть любого размера, который потребуется для выполнения этих функций. Каждой задаче назначается приоритет. Операционная система всегда выполняет задачу с наибольшим приоритетом. Если выполняется задача с низким приоритетом, и в это время назначается задача с высоким приоритетом, то задача с низким приоритетом будет приостановлена, пока не закончится задача с высоким приоритетом. Такая система даёт нам иллюзию, что задачи выполняются одновременно, хотя на самом деле, конечно, задачи выполняются по очереди. Такая система не детерминирована, но её функции понятны и могут быть верифицированы, и она повышает надёжность, безопасность, гибкость в использовании, и, в особенности, простоту разработки.

Executive (операционная система реального времени AGC и LGC. прим. перев.) организовывала выполнение задач таким образом, что каждая задача сохраняла своё состояние в виде набора регистров, и состояние сохранялось, пока выполняется задача с большим приоритетом. LGC содержит массив из восьми наборов по 12 регистров каждый, по 15 бит в регистре. Набор регистров такого размера достаточен для выполнения множества задач, но задачи, использующие интерпретатор (встроенный интерпретирующий язык для задач, оперирующих с числами двойной точности. прим. перев.) для выполнения векторных и матричных вычислений, требуют больше места. Для таких задач выделяется отдельный массив из 43 регистров. LGC содержит пять таких массивов (Vector Accumulator, VAC).

С таким ограниченным набором массивов для сохранения контекста задач, запуск задач на выполнение следует делать очень осторожно. Функции, выполняющиеся последовательно одна за другой, объединялись в одну задачу. Большая задача SERVICER была активна в течение всей фазы посадки и других фаз полёта с включенным двигателем, и она включала в себя навигацию с использованием акселерометров, уравнения движения, управление дроссельной заслонкой двигателя, вывод данных о положении корабля, вывод других данных на дисплей, и каждая функция использовала выходные данные предыдущих.

Количество доступных регистровых массивов и VAC ограничивает количество задач, которые могут стоять в очереди на исполнение восемью, из которых до пяти могут использовать массивы VAC. При нормальной работе, количество запущенных задач остаётся постоянным, хотя задачи, запущенные для однократного исполнения, или асинхронным образом, могут вызывать флуктуации загрузки системы.

Однако, если количество запущенных задач больше, чем завершённых, количество использованных регистровых массивов и VAC растёт. Если эта ситуация продолжается достаточно долго, то их количество иссякает, и запрос на запуск следующей задачи не может быть удовлетворён.

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

Защита от рестарта была реализована при помощи регистрации «путевых точек» в подходящих точках программы, расставленных таким образом, что возврат к последней «путевой точке» не вызывал ошибку, как показано в следующем примере:

NEW_X = X + 1
регистрация путевой точки
X = NEW_X

Очевидно, что без регистрации путевой точки выполнение этого кода второй раз вызовет повторный инкремент X.

После рестарта такая программа возобновляет свою работу. Каждая задача начинает работу с последней зарегистрированной путевой точки. если несколько копий одной и той же задачи находились в очереди, возобновляется только последняя. Некоторые задачи не имеют статус жизненно важных, и не защищены от рестарта. Они просто исчезают.

Защита от рестарта работала очень хорошо. На панели управления нашего гибридного симулятора в Кембридже была кнопка, вызывающая рестарт AGC. При тестировании ПО мы иногда нажимали эту кнопку в случайные моменты времени, почти надеясь, что сбой приведёт нас к ещё одному багу. Неизменно, каждый раз срабатывала защита от рестарта, и работа продолжалась без остановки.

(Гибридный симулятор содержал цифровой компьютер SDS 9300 и аналоговый компьютер Beckmann, реальный компьютер AGC и реалистичные модели кокпитов командного и лунного модулей.)



Предстартовая подготовка Аполлона.

Не только железо могло вызвать рестарт, он мог быть вызван программно, если программа достигала точки, в которой компьютер не знал, как продолжить выполнение программы. Это происходило при передаче управления по метке BAILOUT в модуле «Alarms and Aborts». Вызов сопровождался кодом ошибки.

Эти действия выполнялись системой Executive, если ресурсы исчерпаны. Если задача не может быть поставлена на выполнение из-за того, что нет свободных массивов для сохранения регистров, Executive вызывал BAILOUT с кодом ошибки 1202. Если не было свободного VAC, то вызывался BAILOUT с кодом 1201.

Не все функции, выполняемые в LGC выполнялись как «задачи». Помимо них, были аппаратные прерывания, которые могли возникнуть в любой момент (если не были в явном виде запрещены), которые выполняли высокоприоритетные функции, прерывания были назначены определённым устройствам, включая цифровой автопилот, «uplink» и «downlink» (устройство приёма и передачи данных по радиоканалу с Землёй. прим. перев.) и клавиатуре.

Другие прерывания могли быть использованы для выполнения кусков кода, которые должны быть выполнены в определённое время. Такие функции назывались «задания» (tasks), и их планирование происходило в подпрограмме, называемой WAITLIST. «Задания» должны были иметь очень маленькое время выполнения.

В то время, как «задачи» (jobs) планировались для выполнения с определённым приоритетом, «задания» (tasks) планировались для запуска в определённое время. Задания и задачи часто использовались совместно. Задание могло быть запущено для считывания показаний датчика, которые должны быть считаны в строго определённое время, и задание, в свою очередь, запускало задачу с определённым приоритетом для обработки этих показаний.

Когда Хэл Лэйнинг проектировал Executive и систему Waitlist в середине 1960-х, он делал всё с чистого листа, не опираясь на какие-либо примеры. И его принципы верны и сегодня. Распределение функций по ограниченному числу асинхронных процессов, под контролем исполнительной среды с вытесняющей многозадачностью, основанной на временных интервалах и приоритетах, всё это по-прежнему лежит в основе современных компьютерных систем реального времени для космических применений.



Сборка гироскопов.

* * *

Чтобы понять первопричину алармов на Аполлоне 11 во время спуска, необходимо рассмотреть процедуру сближения с командным модулем, которая следует после подъёма лунного модуля с поверхности Луны на лунную орбиту. Так же, как мы используем радар приземления для измерения высоты и скорости относительно лунной поверхности при посадке на Луну, сближение с командным модулем на лунной орбите требует измерения расстояния, скорости и направления относительно второго корабля с помощью радара сближения.

Радар сближения имеет несколько режимов работы, которые задаются переключателем режима. Эти режимы следующие: SLEW, AUTO, и LGC. В режимах SLEW и AUTO радар работает под управлением команды, независимо от LGC. Такой режим работы мог быть использован при взлёте и сближении при отказе основной системы навигации. В режиме SLEW антенна радара наводится вручную, в остальное время она неподвижна. Когда антенна направлена на цель, можно переключить режим в AUTO (автотрекинг), и она будет отслеживать цель. Радар сближения измеряет расстояние и скорость, а углы поворота валов, на которых поворачивается антенна, отображаются на дисплеях кокпита и на указателях в виде вертикальных шкал. Также данные о расстоянии и скорости поступали в аварийную навигационную систему (abort guidance system, AGS), компьютер, имеющий всего 6144 слов памяти, который дублировал основную систему PGNS при посадке на Луну и взлёте с Луны.

(Названия трёх режимов работы радара сближения были источниками смущения некоторых комментаторов. По просьбе экипажа, обозначения были изменены после миссии LM-1 и до миссии с посадкой на Луну. Режим, который на Аполлоне-11 назывался LGC, раньше назывался AUTO. Режим, который назывался AUTO на Аполлоне-11, раньше назывался MANUAL. Название режима SLEW осталось неизменным. Хотя это никоим образом не способствовало возникновению проблемы на Аполлоне 11, внутренняя документация LUMINARY в разделе, относящемся к дискретному каналу 33, в то время все еще называла режим LGC, в котором радар сближения включен, режимом RR AUTO-POWER ON.)

Если система PGNS работала (как оно и было на самом деле), радаром управлял LGC, и в этом случае переключатель режимов работы радара сближения был установлен в положение LGC. Электроника интерфейса радара позволяла ПО получать данные о расстоянии и скорости, измеренной радаром, а также углы валов вращения антенны, из которых могут быть найдено направление на цель. Программа LGC использовала эту информацию для того, чтобы вести LGC на сближение с командным модулем.

Оказалось, что радар сближения также может работать во время спуска, и это было сделано во время спуска Аполлон-11. Инструкции экипажа требовали, чтобы радар был включен непосредственно перед началом фазы P63 и оставался в режиме SLEW или AUTO в течение всего посадочного маневра.

Было дано много объяснений, почему радар был настроен таким образом для высадки на Луну. Например, некоторые люди в Хьюстоне, возможно, рассматривали причудливую схему мониторинга посадки путем сравнения данных радара с графиком ожидаемых показаний. Однако есть более простое объяснение: радар включался перед посадкой только для того, чтобы оставаться прогретым на случай аварии при прерывании, и находился в режиме AUTO (если лунный модуль находился в положении, позволяющем отслеживать командный модуль) или SLEW (в другое время), просто чтобы не допустить бесполезные перемещения антенны.



Рис 7. Интерфейсы PGNS, ATCA и радара сближения

Эта проблема часто атрибутировалась (в том числе и автором ранее) просто как ошибка в чеклисте. Это неточная формулировка, также, как неточным является назвать преждевременное выключение монитором
delta-V двигателя лунного модуля «компьютерной ошибкой», в то время, как на самом деле ошибка была в документации. Фактически, положение переключателя радара сближения Аполлона 11 не должно было вызвать никаких проблем. Но отсюда можно проследить другой случай ошибки в документации.

За годы до этого, была написана документация на интерфейсы управления (interface control document, ICD), который определяет электрический интерфейс между PGNS и электронной сборкой ATCA (attitude and translation control assembly), которая поставлялась Grumman Aerospace, компанией, построившей посадочный модуль. ICD определял, что цепи питания 28В частотой 800 Гц в двух системах должны быть выровнены по частоте, но не написано, что они должны быть синхронизированы по фазе. По факту, две системы выравнивались по частоте сигналом «frequency sync», посланным LGC. Они имели постоянное отношение фаз. Однако, фаза между двумя напряжениями была полностью случайной величиной, зависящей от момента, в который LGC, который всегда запитывался позже ACTA, начал слать сигнал синхронизации. Эти интерфейсы показаны на рис. 7.

Проблема с фазой 800 Гц была обнаружена при тестировании посадочного модуля LM-3 и задокументирована, но никогда не была исправлена. В результате, когда переключатель режимов работы радара находился в положении AUTO или SLEW, поворотный механизм радара возбуждался сигналом 800 Гц от ATCA, который с высокой вероятностью не совпадает по фазе с сигналом 800 Гц, который используется как опорный в блоках CDU, которые преобразуют сигналы от механизма поворота в данные для компьютера, и нкрементируя (или декрементируя) счётчики в компьютере, которые сообщают программе, как повёрнута антенна.

На Аполлоне 11, однако, CDU работали иначе. Поскольку они принимали в качестве опорного сигнала отдельно генерируемое напряжение, сигналы датчиков угла антенны, принятые CDU, показывали неизвестный угол. Ошибка была наибольшей, если разность фаз была близка к 90 или 270 градусов, и Аполлон 11, очевидно, попал в одну из этих интересных точек. В ответ CDU начинало инкрементировать или декрементировать счётчики LGC с почти постоянной скоростью, около 6400 импульсов в секунду для каждого из углов. Это происходило каждый раз, когда переключатель был в режиме SLEW или AUTO, вне зависимости от того, был ли включен радар сближения.

Счётчики интерфейса CDU в LGC инкрементировались или декрементировались внешними сигналами, которые обрабатывались в компьютере. Это отнимало время, в данном случае один цикл памяти 11,7 мкс каждый. Если счётчики инкрементировались с максимальной скоростью, это отнимало примерно 15% всего времени (это паразитное время называется TLOSS). В настоящее время мы даём консервативную оценку затрат времени 13%, что согласуется с наблюдаемым поведением.

После полёта Аполлона 11 инженеры компании Grumman провели тесты в попытке воспроизвести поведение компьютера, наблюдавшееся в полёте. Они подтвердили, что даже в наихудшем случае CDU не могли посылать импульсы с максимальной скоростью. Они пришли к тому, что максимальная загрузка компьютера этими счётчиками (TLOSS) могла быть 13,36%. При симуляции воспроизводились ошибки, подобные тем, что произошли в полёте. Таким образом, приведённое значение TLOSS является наилучшей задокументированной оценкой загрузки компьютера Аполло 11. [Clint Tillman, «Simulating the RR-CDU Interface When the RR is in the SLEW or AUTO (not LGC) Mode in the FMES/FCI Laboratory,» August 9, 1969]

Я в долгу перед экспертом по системе наведения лунного модуля Джорджем Силвером (George Silver) за его терпеливые разъяснения интерфейса радара сближения лунного модуля. Он играл центральную роль в миссии Аполлон 11. В момент старта он был на мысе Канаверал, затем полетел в Бостон, в Кембридж, чтобы принять дежурство по мониторингу взлёта с Луны. Посадку на Луну он наблюдал дома по телевизору 20 июля. Он слышал звуки алармов, догадался, что что-то отнимает время компьютера, и вспомнил случай, который он видел в процессе тестирования систем LM-3, когда радар сближения вызвал бешеную активность счётчиков. После некоторого дополнительного анализа командой мониторинга миссии в Кэмбридже, Силвер наконец связался с представителями MIT в Хьюстоне, утром 21 июля, меньше чем за час до взлёта с Луны.



Фрагмент алгоритма ручного управления

* * *

Посадка на Луну была самой напряжённой фазой полёта. Система управления посадкой должны были достичь цели с определёнными координатами, имея определённую скорость, ускорение, степень рывков (степень изменения/ ускорения). Кламп (Klumpp) называл скорость изменения «рывка» (jerk) «щелчком» (snap), а следующие две производные назывались треск" (crackle) и «поп» (pop). В фазе видимости (то есть когда поверхность Луны была видна в иллюминатор корабля. прим. перев.) программа позволяла экипажу изменить место посадки. Дроссельная заслонка управлялась непрерывно. Навигация включала в себя измерения с помощью радара посадки. На рис. 8. показан типичный профиль нагрузки между выбором фазы P63 и касанием поверхности луны.



Рис. 8: Нагрузка на протяжении посадки (данные симулятора)

Даже при этих условиях, мы пытались сделать наши программы достаточно быстрыми, чтобы иметь достаточный запас по времени на случай большого TLOSS. Главным ограничением был двухсекундный период, который был встроен в программу «average-G», используемую в стадии полёта. Это был период, с которым задача READACCS читала показания акселерометров и запускала задание SERVICER, которая использовала эти значения в качестве исходных данных для новой итерации расчётов траектории, дросселирования двигателя, определения положения корабля и отображения на дисплее. На протяжении посадки, степень загрузки компьютера просто показывала, сколько времени было потрачено на исполнение задач и прерываний на протяжении каждого двухсекундного периода.

В течение фазы торможения, до тех пор, пока радар приземления не увидел поверхность, запасное время было не менее 15%. После того, как радар введён в действие, начинаются дополнительные вычисления, связанные с переводом координат из системы отсчёта радара в систему координат для навигации, которые уменьшают запас до 13%. Когда запускается отображение данных на дисплее (глагол 16, существительное 68), запас уменьшается до 10% или ниже. Баз Олдрин был проницателен, когда сказал после сигнала 1202, «похоже, он появился когда мы ввели 1668» [16].

Когда запас 10%, а отнимается 13%, LGC не имеет достаточно процессорного времени для выполнения всех требуемых функций. Благодаря гибкости дизайна Executive, и в отличие от того, что случилось бы с жесткой архитектурой, катастрофы не произошло.

Таблица 1. Задачи, активные при посадке на Луну.


В таблице 1 перечислены задачи, активные при посадке Аполлона 11. SERVICER имеет самый низкий приоритет, и выполняется дольше всего. Высокоприоритетные задачи могут останавливать работу SERVICER, но они имеют относительно малое время выполнения.

Так как SERVICER имел низкий приоритет из-за своего большого размера, он и сломался из-за нехватки вычислительного времени. С отрицательным запасом по времени, SERVICER не успел выдать ответ, когда в очередной раз запустился READACCS, который запускался по расписанию, и запустил SERVICER снова. Так как предыдущая копия SERVICER не закончила вычисления, она не освободила массивы регистров и VAC, и READACCS вызвал FINDVAC, чтобы Executive выделил новый массив регистров и VAC и запустил SERVICER. Этот SERVICER тоже не заканчивал работу вовремя. После короткого цикла таких операций массивы регистров и VAC заканчивались. Когда к Executive приходил следующий запрос, вызывался BAILOUT с кодом 1201 или 1202.



Рис 9: Работа SERVICER без и с TLOSS

Рис. 9 показывает, как SERVICER ведёт себя при сильном TLOSS, и на рис. 10 приведено сравнение графиков использования наборов регистров и VAC при нормальной работе и при сильном TLOSS, при которой происходит рестарт.



Рис. 10. Эффект, производимый TLOSS на ресурсы Executive и Waitlist на протяжении посадки на Луну (данные симулятора, начинаются с фазы P63 перед получением данных о скорости с радара, и заканчиваются посадкой[17].)

Интересный эффект такой последовательности событий, в течении фазы P63, был в том, что проблема устранила саму себя. Программный рестарт восстановил только самую последнюю копию задачи SERVICER, и удалил все незавершённые копии SERVICER. Вдобавок, он завершил все функции, не имеющие защиту от рестарта, потому что они не являются критическими, включая монитор DELTAH (глагол 16, существительное 68). Это стало причиной того, что после двух алармов в P63, дисплей переключился с значения «существительное 68» к значению «существительное 63».

Система защиты от рестарта была изначально разработана из-за возможных сбоев аппаратного обеспечения, обеспечила снижение вычислительной загрузки при большом TLOSS. Разработанная нами система реального времени оказалась отказоустойчивой в определённых условиях.

В течение фазы P64 ситуация была иной. В дополнение к обычным уравнениям движения добавилась дополнительная обработка, которая включала возможность переназначения места посадки. Дополнительные функции программного обеспечения оставляют запас по времени меньше 10%. Алармы продолжали возникать. Произошло три аларма 1201 и 1202 в течение 40 секунд. Каждый раз программное обеспечение выполняло рестарт, очищая очередь задач, но не могло уменьшить нагрузку.

Время миссии 102:43:08, предвидя следующий аларм, Армстронг переключил автопилот из AUTO в ATT HOLD режим, ослабив вычислительную загрузку, и затем вошёл в полуручной режим P66, в котором загрузка компьютера была мала. Через 2 минуты и 20 секунд маневрирования в фазе P66, лунный модуль сел.