[Перевод] Погружение в недра бортового управляющего компьютера «Аполлона» и хак, спасший миссию «Аполлон-14»
Как, находясь на Земле, пропатчить программу на компьютере, летающем вокруг Луны? Очень осторожно.
Миссия «Аполлона-14», которой командовал Алан Шепард (единственный астронавт из программы «Меркурий», летавший на Луну в составе миссии «Аполлон») была повторением плана посадки на Луну «Аполлона-13», от которой в своё время отказались. Шепард в компании пилота лунного модуля Эда Митчелла и пилота командного модуля Стю Русы нацеливались на кратер Фра Мауро — холмистую местность неподалёку от Лунного экватора и недалеко к югу от гигантского кратера Коперника. Считалось, что Фра Мауро, появившийся, скорее всего, благодаря выбросу вулканом пород во время создания Моря Дождей, содержит материалы из глубин Луны, которые могут пролить свет на происхождение нашего спутника.
За восемь месяцев с момента неудачного полёта «Аполлона-13» инженеры внесли несколько изменений в космический корабль с целью уменьшения вероятности повторного взрыва. Чтобы гарантировать возвращение команды домой в случае очередной внештатной ситуации, добавили дополнительный бак с кислородом и аккумулятор. Незапланированная пауза дала время на обновление программ в компьютере лунного модуля; особенно долгожданной стала возможность компьютера распознавать изменения высоты поверхности при приближении к месту посадки. Благодаря этому компьютер уже не запутывала волнистая поверхность спутника на подлёте спускаемого аппарата к поверхности.
Команда Аполлона-14, 11 января 1971 года. Слева направо: Эд Митчелл, Эл Шепард и Стю Руса.
Официальный портрет команды, декабрь 1970
Митчелл, Шепард и Руса готовятся к прогону на симуляторе в космическом центре Кеннеди, 26 января 1971. До запуска всего пять дней.
Шепард на фоне симулятора лунного модуля, 26 января 2971
Завтрак перед запуском, утром 31 января 1971. Слева, по часовой стрелке: пилот лунного модуля Эл Митчелл, главный астронавт Том Стэффорд, пилот лунного модуля Стю Руса, командир Эл Шепард, глава полётных операций Дик Слейтон, запасной пилот лунного модуля Джо Ингл и запасной пилот командного модуля Рон Эванс
Командир Шепард во время процедуры одевания перед стартом
Задумчивый Руса во время одевания
Команда «Аполлона-14» идёт по коридору в фургон для перевозки
Команда садится в фургон, который доставит их к ожидающей ракете «Сатурн-5»
Команда в Белой комнате рядом с капсулой, с лидером пусковой команды Гюнтером Вендтом. В рамках традиционного обмена подарками перед запуском команда подготовила для Вендта шлем полковника Клинка [отсылка к американскому ситкому Hogan’s Heroes 1970-х годов про немецкий лагерь военнопленных Второй мировой / прим. перев.], а тот подготовил для Шепарда тросточку — намёк на то, что в случае успеха миссии 47-летний Шепард станет самым старым человеком, ступавшим на луну [надпись на записке для трости: поддерживающее оборудование для лунного исследователя]
Все, что случилось с нами, лишь пролог*
[У. Шекспир, «Буря» / прим. перев.]
Днём 31 января 1971 года космическая ракета Сатурн-5 с грохотом взлетела с космического центра им. Кеннеди, задержавшись всего на 40 мин из-за погоды. Перезапустив третью ступень S-IVB для выхода на траекторию к Луне, командный модуль «Китти Хок» с командой отправились в сторону нашего спутника.
Почти сразу после постановки на траекторию выхода на орбиту вокруг Луны появилась серьёзная проблема, когда «Китти Хок» попытался пристыковаться к лунному модулю миссии, «Антаресу». Защёлки размером с ноготь на стыковочном модуле не смогли захватить его, и два космических корабля не сумели состыковаться. Только после нескольких попыток «Китти Хок» смог удачно поймать и надёжно присоединить к себе «Антарес». После этого S-IVB отправили на одинокую, но яркую смерть, и комбинированный корабль «Аполлон-14» продолжил свой путь к Фра Мауро.
Четыре дня путешествия оказались небогатыми на события — по крайней мере, для путешествия на Луну. Выход на лунную орбиту случился на 82-й час полёта. Для экономии ценного топлива в лунном модуле комбинированный корабль снизился, через несколько часов заняв орбиту с перигеем в 14,5 км. На следующий день с активации и проверки лунного модуля началась подготовка к спуску.
Однако всего за четыре часа до запланированной посадки диспетчеры заметили, что, судя по индикации на консолях в центре управления полётом, нажата кнопка отмены на лунном модуле. По радио Шепард подтвердил, что на борту «Антареса» никто не нажимал кнопку отмены –, а это означало, что где-то в запутанных кишочках лунного модуля произошло короткое замыкание или иная электрическая проблема.
Такая проблема в потенциале могла и закончить миссию: если кнопка нажата, а двигатель работает, то лунный модуль должен немедленно начать процедуру отмены сразу после спуска, что сделает посадку невозможной.
SA-509, ракета Сатурн-5, которая должна доставить Аполлон-14 на Луну, выкатывается из здания вертикальной сборки на гусеничном транспортёре. Утро 9 ноября 1970 года.
SA-509 на взлётной площадке 39А во время теста обратного отсчёта, 19 января 1971
SA-509 медленно карабкается в небо, 31 января 1971
Снимок запуска Аполлона-14 с камеры, расположенной на башне запуска. Сверху видно командный модуль «Китти Хок» в защитной облочке.
Третья ступень SA-509 отбрасывается перед извлечением лунного модуля. На её передней части всё ещё находится лунный модуль «Антарес»
Широкоугольный снимок 2-й комнаты центра управления в Хьюстоне во время исправления ошибки с извлечением лунного модуля. На самом правом экране видно, что «Антарес» всё ещё ожидает отсоединения от S-IVB
В условиях ограниченного времени в центре управления нужно было быстро понять, что не так, и придумать способ обойти эту проблему. В итоге они придумали самый гениальный из всех компьютерных хаков в истории миссии «Аполлон», и, возможно, за всю историю электронных компьютеров.
Чтобы точнее пояснить, что это был за хак, как он работал, и с какими проблемами столкнулись разработчики во время его создания, нам нужно сильнее углубиться в работу бортового управляющего компьютера «Аполлона». Держитесь — мы погружаемся.
Разбираем бортовой управляющий компьютер «Аполлона»
Бортовой управляющий компьютер «Аполлона» часто описывают как обычный калькулятор, или сравнивают с чипом контроллера часов или микроволновки. Однако ваши часы кроме времени мало что показывают. Управляющий микроволновкой чип тупо запускает и останавливает магнетрон для разогрева курочки с истёкшим сроком годности. У этих устройств происходит мало взаимодействия с окружающим оборудованием, они не проводят сложных вычислений и не принимают решений.
Описывая «компьютер», ожидаешь, что у этой системы найдутся возможности, которые мы приписываем современным компьютерам — к примеру, способность запускать несколько программ одновременно, или выдавать простой и интуитивно понятный интерфейс, управлять широким спектром устройств и аккуратно восстанавливаться после ошибок в приложениях. «Ха!» — можете воскликнуть вы, «да я в кармане ношу такой компьютер!»
В идею о том, что подобные возможности существовали почти 60 лет назад, верится с трудом, однако у бортового управляющего компьютера «Аполлона» было и это, и многое другое. Интерпретатор для обработки «виртуальных» машин, похожий на байт-код Java? Есть. Возможность удалённого обновления данных? Ага. Учитывая все эти возможности, разумно сравнивать бортовой управляющий компьютер «Аполлона» с современным смартфоном. Да, бортовой управляющий компьютер «Аполлона» был медленнее, у него было куда как меньше памяти, но лишь из-за неудачной даты рождения, из-за чего он оказался не на том конце кривой закона Мура.
И хотя процессор, выполнявший по 80 000 инструкций в секунду, был не особенно быстрым, сложно преувеличить ограничения, накладываемые скудным объёмом его памяти на разработчиков ПО. Представьте себе эти ограничения: все программы для полёта на Луну и обратно должны были умещаться в 36 К слов (слова по 15 бит, плюс бит чётности), на памяти только для чтения на прошитых магнитных сердечниках. И поскольку бортовой управляющий компьютер «Аполлона» не работал с «байтами», все 15 бит слова считывались за один раз, и простого способа разбить слово на более мелкие составляющие не было.
Несколько дисковых накопителей IBM 2314 (белые) и устройство для чтения и перфорирования перфокарт IBM 2540, 1968 год.
Дополнительный накопитель использовать было нельзя — дисковые модули, которые тогда были размером со стиральную машину, не поместились бы в космический корабль. Магнитную ленту, надёжный и реальный вариант, рассматривали уже слишком поздно для того, чтобы включать её в проект компьютера. Все программы бортового управляющего компьютера «Аполлона» содержались внутри модулей на прошитых сердечниках внутри самого компьютера — это была коробка весом 32 кг и размерами 61×32х17 см.
В дополнение к 36К слов памяти только для чтения, у бортового управляющего компьютера «Аполлона» была RAM всего на 2К слов — это было необходимо для работы операционной системы, управления процессами, восстановления и глобальных переменных всех фаз миссий. И всё. В эту жалкого размера память были втиснуты выделенные области памяти, используемые приложениями: программами, выполнявшими задачи навигации и управления, приземлением на Луну и встречами. Каждой базовой программе выделялось целых семь слов на хранение временных переменных. Нет, это не опечатка.
Легко быть циничным, вспоминая все эти ограничения при установке на ноутбук какой-нибудь новой программы, занимающей несколько гигабайт.
Бортовой управляющий компьютер «Аполлона» (слева), с модулем интерфейса дисплея и клавиатуры (справа). Размер компьютера 61×32×17 см
Как работал бортовой управляющий компьютер «Аполлона»: задачи и задания
В начале 1960-х, в ранние дни микрокомпьютеров, было совершенно нормально использовать компьютер с редкими обращениями к монитору. Вы загружали одну программу, давали ей отработать, а потом просматривали её вывод. Довольно быстро стало понятно, что такой способ очень сильно тратит ресурсы, и в мейнфреймах появилось понятие «мультипрограммирования», кардинально улучающее утилизацию системы. А небольшим компьютерам, которым недоставало памяти, поддержки оборудования и инструментов для системного программирования, оставалось запускать свои отдельные приложения по очереди.
И хотя бортовой управляющий компьютер «Аполлона» был реально небольшим компьютером для своего времени, выполнение программ по одной не устраивало его проектировщиков. Компьютеру космического корабля с широким диапазоном запросов к быстродействию требовался какой-то пользовательский интерфейс, и ввиду непредсказуемых колебаний трафика ввода и вывода выполнение программ по отдельности отмели сразу же. Было необходимо реализовать ОС с мультипрограммированием — способную разбивать работу на удобоваримые кусочки и планировать их исполнение по необходимости.
На бортовом управляющем компьютере «Аполлона» выполнялись программы двух типов — «задачи» [jobs] и «задания из списка ожидания» [waitlist tasks]. Задачи запускались независимо, у них была крохотная выделенная область в памяти для переменных, и они пользовались приоритетом в очереди на запуск.
Модуль интерфейса дисплея и клавиатуры бортового управляющего компьютера «Аполлона» на своём месте в командном модуле «Аполлона» (у командного модуля обычно был запасной модуль интерфейса дисплея и клавиатуры, расположенный в нижнем отсеке)
Модуль интерфейса дисплея и клавиатуры бортового управляющего компьютера «Аполлона» в лунном модуле. На переднем плане — справочная таблица.
Внутри модуля на прошитых сердечниках. После изготовления такие модули обычно заливали эпоксидкой для защиты от вибраций. В данном модуле эпоксидки нет, и видно сердечники.
Внутри модуля бортового управляющего компьютера «Аполлона» с плоским корпусом и дискретной электроникой
Модули внутри бортового управляющего компьютера «Аполлона»
Почти все задачи были не большими программами, которые бы преимущественно ничего не делали и отъедали ресурсы — это были небольшие программки, работавшие недолго, и с узко определёнными функциями. По завершению работы задача планировала свой запуск на некий момент в будущем, или заканчивала выполнение, ожидая, что её перезапуск запланирует какая-нибудь другая задача. Таким образом задачи постоянно создавались и прекращались, и количество работы, требовавшееся от компьютера, очень сильно менялось в зависимости от фазы миссии.
В отличие от других систем того времени, где запуск и прекращение процесса было делом трудоёмким, планирование выполнения задач на бортовом управляющем компьютере «Аполлона» было тривиальным. На современных системах создаются виртуальные адресные пространства и области страничного обмена, процедуры выделения памяти резервируют рабочие области хранения, создаётся сложное безопасное окружение. Ничего такого не требовалось для бортового управляющего компьютера «Аполлона» (и даже концепций таких во время его разработки не существовало). Всё, что требовалось, это запросить свободное место («набор сердечников») в таблице процессов, и передать управление программе. Закончить процесс было так же просто — задача запрашивала очистку выделенного для процесса места, и в этот момент переставала существовать.
Процесс выполнения программ бортового управляющего компьютера «Аполлона» тщательно контролировался, чтобы гарантировать наличие свободных наборов сердечников для выполнения нужного количества задач на каждой стадии полёта. Если бортовой управляющий компьютер «Аполлона» не смог бы найти свободный набор сердечников — чего не должно было быть — он выдавал программный сигнал тревоги »1202». И так сложилось, что это невозможное событие действительно произошло во время посадки «Аполлона-11», и только быстрая реакция центра управления исправила ситуацию, которая иначе могла бы обернуться опасной отменой посадки.
Что важно для компьютера, работающего в реальном времени, у задач была примечательная способность определять точку, с которой их можно было бы перезапустить при появлении в системе проблемы. Логика обработки была разработана так, что когда программа доходила до важной фазы вычислений, можно было определить точку перезапуска. В случае перезапуска системы (но не полной перезагрузки, которая стёрла бы все данные в RAM), данные в памяти сохранялись, и задача могла возобновлять работу с предварительно заданной точки перезапуска так, будто ничего не произошло. Такая способность оказалась полезной во время проблем с посадкой «Аполлона-11», когда компьютеру пришлось перезапускаться много раз, но он продолжал вести лунный модуль к цели посадки без проблем.
Часть комплекса вычислений в реальном времени, расположенного на первом этаже центра управления полётами в Хьюстоне. НАСА использовало несколько мейнфреймов IBM System/360 для обслуживания каждой миссии «Аполлон», но на космических кораблях и близко не было места для размещения мейнфрейма целиком
На дисплее и клавиатуре (которые называли DSKY, и произносили как слово, рифмующееся с «виски») расположено немного сбивающее с толку поле под названием PROG, сокращение от program. Обычный наблюдатель может ошибочно решить, что в этом поле видна программа, работающая в данный момент на бортовом управляющем компьютере «Аполлона» (проигнорировав тот факт, что в фоне работают множество других процедур). Точнее сказать, там демонстрируется номер программы под названием «основной режим», отражающий фазу полёта или навигации, которую астронавту нужно завершить. При этом дисплей основного режима в основном нужен был только для членов команды, чтобы они понимали цель исполняющейся в данный момент программы. Лишь в нескольких местах к числу, демонстрировавшемуся на этом дисплее, обращались другие программы — и как раз один из этих случаев оказался критически важным для нашей истории.
Задания из списка ожидания представляли собой нечто совсем иное, нежели задачи. По определению это ещё более простые программы, чем задачи — это были чрезвычайно короткие и критически важные задачи, которым не нужны были выделенная память или сложное управление процессами. На считывание угла поворота инструмента или данных акселерометра из модуля измерения инерции уходило всего несколько машинных инструкций, однако эта работа была необходима для вычислений, проводившихся программами навигации, ориентирования и управления. Поэтому было жизненно важно выдавать данные, полученные с модуля измерения инерции, через точно заданные временные промежутки, из-за чего задания выполнялись по жёсткому графику.
Другие задания из списка ожидания отвечали за отключение маневровых двигателей, запускаемых цифровым автопилотом, или проверку факта нажатия упомянутой ранее кнопки отмены. Эти задания запускались по заранее установленным таймерам, и работали, подавляя все другие события, поскольку ожидалось, что каждое из них будет длиться лишь крохотную долю секунды.
Как создавали виртуальные машины в 1960-х
На бортовом управляющем компьютере лунного модуля могло выполняться до восьми задач одновременно (и до семи в компьютере модуля командования и обслуживания), и из этих восьми в пяти мы могли бы сегодня признать, с некоторыми допущениями, «виртуальные машины». Каждая из них могла выполняться независимо, со своим собственным приоритетом, хотя и без изолированного адресного пространства.
Это может показаться странным, но некоторым из наиболее загруженных задач был назначен более низкий приоритет. Основная процедура посадки на луну, Program 63 (или просто P63), имела более низкий приоритет, чем большая часть остальных задач. И это имело смысл, поскольку объём и сложность Р63 легко могли монополизировать все вычислительные ресурсы компьютера. Назначив этой интенсивной задаче низкий приоритет, ей позволяли выполнять небольшие, короткие, но критически важные отрезки работы. Во многих случаях эти мелкие программы выполняли жизненно важные операции — управление ориентацией корабля, чтение данных с радара, обновление дисплеев астронавтов.
Чарльз Старк Дрейпер, основатель и директор Лаборатории измерительных приборов Массачусетского технологического института (позже была отделена от института и переименована в Лабораторию Чарльза Старка Дрейпера), изучает макет системы контроля «Аполлона», 1963
Железо в основе бортового управляющего компьютера «Аполлона» страдало от извилистой эволюции компьютера, следы которого начинаются с 1960-го года, с компьютера, разработанного для предполагавшейся миссии на Марс. К тому времени, как с MIT заключили контракт на создание бортового компьютера для управления и навигации «Аполлона» в 1961, «марсианский компьютер» развился уже до того, что умел выполнять восемь разных машинных инструкций и работал с памятью из 4К слов. Этого было смехотворно мало даже для полёта на Луну, однако разработка железа и софта с нуля просто не укладывалась в назначенные президентом США Кеннеди сроки «до конца десятилетия». Это железо взяли за точку отсчёта и изо всех сил развивали, выжимая из архитектуры всё, что только можно.
Однако и такой вынужденной эволюции оказалось недостаточно — железу недоставало жизненно важных способностей. Программам для космического корабля требуются сложные операции — работа с матрицами, тригонометрические функции, множество переменных большой точности. Эти требования могла бы удовлетворить объёмная библиотека ПО, однако постоянные вызовы и возвраты из бесконечных библиотечных функций съели бы всю ограниченную память и вычислительные возможности. Требовалось более удачное решение. И для создания совершенного новой среды для выполнения программ была придумана совершенно новая (для того времени) техника программирования, повлекшая за собой создание новой программной «архитектуры».
Чтобы справиться с ограничениями бортового управляющего компьютера «Аполлона», разработчики создали программу-«интерпретатор» — и это подводит нас к «виртуальной машине».
Для начала представил новый язык с новой стэковой префиксной нотацией. Выделялись области памяти впечатляющего объёма в 43 слова («область накопления векторов, или VAC), по одной для каждой из одновременно запущенных интерпретируемых программ, общим числом до пяти. Как и набор сердечников, эти VAC были ограничены, и ими приходилось тщательно управлять, поэтому казалось невозможным, что они могут исчерпаться. Иначе же вызывалась программная тревога »1201».
В «интерпретаторе» операции были совершенно непохожи на машинные инструкции, использовавшиеся в других частях кода бортового управляющего компьютера «Аполлона». Одна-две инструкции упаковывались в одно слово, за которым следовал список адресов, с которыми нужно было работать инструкции. Работавшие в «интерпретаторе» программы жировали на списке инструкций из 128 новых операций, в которых новое окружение реализовывало необходимые для полёта математические операции.
Кроме того, окружение «интерпретатора» обеспечивало функции, которых не было у железа. Сюда входили возможности, знакомые программистам ПО, работающим с языками высокого уровня — индексные регистры, сложное ветвление программ, маски. Вся эта новая сложная функциональность «интерпретатора», реализованная с использованием менее 2,5К слов, создавала совершенное новое программное окружение. Кроме высокоуровневых функций, «интерпретатор» скрывал изощрённую систему работы с банками памяти — к облегчению разработчиков бортового управляющего компьютера «Аполлона». Не будет преувеличением сказать, что созданное «интерпретатором» окружение по многим параметрам похоже на современные виртуальные машины.
Язык модуля интерфейса дисплея и клавиатуры
Читая эту статью, редактируя фотографии из своей коллекции, просматривая очередную фотку с котиком, вы взаимодействуете с богатым графическим интерфейсом, делающим навигацию по экрану относительно безболезненной. Но элементы взаимодействия с компьютером, очевидные сегодня, являются результатом проб и ошибок, многолетних экспериментов и изучения фокус-групп.
Но как спроектировать интуитивно понятный и интерактивный интерфейс для компьютера, работающего в реальном времени, если раньше никто этого не делал? Также важно понять, как должен выглядеть дисплей, какие данные потребуются астронавту для выполнения миссии, и в каком формате.
Инструменты блока II командного модуля «Аполлона». Сможете найти модуль интерфейса дисплея и клавиатуры?
Рубки самолёта и космического корабля кажутся перегруженными, каждый кусочек доступного пространства покрыт измерительными приборами, специальными инструментами и переключателями. Куда втиснуть подобный интерфейс? Традиционную QWERTY-клавиатуру никогда не рассматривали в качестве варианта для бортового управляющего компьютера «Аполлона». Можно представить себе трагикомическую картину — астронавт в неуклюжих перчатках в условиях сильного ускорения и вибраций пытается вбить критически важную команду.
Модуль интерфейса дисплея и клавиатуры разрабатывали так, чтобы он играл роль интерфейса, и предлагал цифровую клавиатуру совместно с клавишами для специальных операций; дисплей из трёх-пяти цифровых регистров, куда можно было вводить данные и откуда их можно было считывать; десятки лампочек, сигнализирующих о проблемах. Три дисплея поменьше показывали работающую в данный момент программу (т.н. «основной режим», упомянутый ранее), и тип данных, с которыми она работает. Да, и там было поле, мигавшее, когда компьютер был занят — вероятно, чтобы демонстрировать команде активность процесса, который иначе никак не увидеть.
Хорошо проработанный интерфейс должен определять язык общения пользователя и машины — превращающий нужды и желания пользователя в запросы, которые легко будет понять программе. В результате гениального прозрения такой «язык» бортового управляющего компьютера «Аполлона» основывался на общении людей.
Представьте, что к вам на улице подходит человек с минимальным знанием языка, и говорит просто «есть, пицца». С грамматической точки зрения эта фраза нелепа, но через какое-то время вы догадываетесь, что человек хочет есть, и есть пиццу. Несколько жестов, и вы направляете его в сторону ближайшего ресторана. Ключевым моментом данного общения является наличие действия, обозначаемого глаголом [verb], и объекта, обозначаемого существительным [noun].
Подобное общение настолько интуитивно, что компьютеры использовали комбинации глагол-существительное. Мы видим, что от машинных инструкций (ADD [Memory Location]), команд (EDIT LETTER.TXT) и до графических интерфейсов (File > Print > taxes.xls) такие конструкции используются повсеместно.
Неудивительно, что на модуле интерфейса дисплея и клавиатуры выделяются две кнопки — VERB и NOUN.
Расшифровка модуля интерфейса дисплея и клавиатуры от бортового управляющего компьютера «Аполлона»
Другие клавиши модуля интерфейса дисплея и клавиатуры тоже довольно ожидаемые. Клавиша ENTER командует компьютеру принять только что введённые данные, клавиши ± обеспечивают знак десятичных чисел, клавиша PRO (сокращение от «PROCEED») позволяет астронавту принять новое событие — запуск двигателя или новую фазу программы.
Поскольку бортовой управляющий компьютер «Аполлона» — система мультипрограммная, может случиться так, что процедуре необходимо выдать данные команде в то время, как другая программа уже взаимодействует с астронавтом. Лампочка KEY REL (от «KEYBOARD RELEASE») сигнализирует, что другая программа требует внимания, и запрашивает освобождение клавиатуры с тем, чтобы она смогла использовать дисплей. Нажатие KEY REL очищает текущий дисплей и выдаёт астронавту новые данные из процедуры, работавшей в фоне.
Диалог с бортовым управляющим компьютером «Аполлона» ведётся посредством комбинации числовых глаголов и существительных. Глаголы можно использовать для ввода или запроса данных. Но каких? На этот вопрос отвечает существительное. К примеру, последовательность запроса компьютера о выводе на дисплей времени грядущего запуска двигателя на модуле интерфейса дисплея и клавиатуры выглядит так:
VERB 06 ENTER, NOUN 33 ENTER
VERB 06 — запрос на вывод десятичного числа, NOUN 33 уточняет, что запрос касается параметра «время зажигания». Компьютер реагирует при помощи трёх дисплеев («регистров»), выводя на них час, минуту и секунду, в которую должен заработать двигатель. Некоторые глаголы работают сами по себе, к примеру, VERB 57, сообщающий компьютеру, что данные с посадочного радара лунного модуля достоверные, и их можно включить в уравнения управления приземлением.
Понимаю разочарование людей, ожидавших детального учебника по работе с компьютером. На самом деле, это, в общем-то, и всё. Прелесть бортового управляющего компьютера «Аполлона» и модуля интерфейса дисплея и клавиатуры в том, что практически всё взаимодействие с ними шло через простые глаголы и существительные. Однако помнить около 100 глаголов и примерно столько же существительных довольно сложно, поэтому «подсказки» для кодов были закреплены на панелях модуля интерфейса дисплея и клавиатуры в модуле командования и обслуживания и лунного модуля.
Подсказка с глаголами и существительными
Ещё одна подсказка, из нижнего отсека командного модуля «Аполлона» (эта ограничена командами, связанными с навигацией)
Подготовка к Фра Мауро: проблема с отменой
Лунный модуль «Аполлона» был чудом инженерной мысли. Обе нереально лёгкие части космического аппарата, для фаз подъёма и спуска, были оптимизированы для своих этапов миссии. Для посадки на Луну требуются большие топливные баки, опорные стойки, и, самое важное, большой маневровый двигатель. И хотя для посадки всё это было необходимо, оно стало бы мёртвым грузом при возвращении — поэтому от него избавились на поверхности, и на орбиту вышла только подъёмная ступень. По сути, ничего кроме кабины, небольшого двигателя и системы жизнеобеспечения, рассчитанной на сутки, там не было, и эта ступень привезла команду и их научные изыскания обратно к ожидавшему на орбите командному модулю.
Общая схема посадки на Луну. Аэродинамические профили или парашюты отпадают из-за отсутствия атмосферы, и остаётся только один способ — посадка на ракете.
Как конкретно происходит посадка на Луну на «Аполло-14». Скан с полётного плана показывает все шаги, которые необходимо выполнить.
Продолжение плана посадки, сразу после старта двигателя и до момента, когда проходит три минуты (TD+3). В таблице, кроме прочего, перечислены ожидаемая скорость посадки и высота.
Процедуры отмены работы лунного модуля пользовались наличием двух отдельных ступеней. Если проблема появлялась на ранних стадиях спуска, то весь корабль возвращался на орбиту при помощи работающего двигателя для спуска. На поздних стадиях спуска, когда в ступени спуска практически заканчивалось топливо, её отсоединяли и запускался подъёмный двигатель, возвращавший команду в безопасность.
Примерно через 45 минут после расстыковки для спуска на Луну, команда «Антареса» была всецело занята проходом по списку необходимых действий, выстраивая систему наведения и обеспечивая готовность лунного модуля к спуску. На Земле командам в Хьюстоне было известно о работе лунного модуля и его систем гораздо больше. Телеметрия, преодолевавшая расстояние от Луны до Земли со скоростью в 50 Кб/с, содержала огромное количество информации по кораблю, большая часть которой команде была не видна.
Именно в этот момент на контрольной консоли GUIDO в Хьюстоне, которая наблюдала за компьютерными системами, заметили, что установлен бит статуса, отвечающий за нажатие кнопки Abort (отмены). Такого очевидно не должно было происходить — если только команда не нажала эту кнопку, а Шепард с Митчеллом категорически подтвердили, что они этого не делали.
Затем команде отправили запрос на демонстрацию канала I/O, где содержался бит отмены. Команда ввела команду:
VERB 11 ENTER, NOUN 10 ENTER, 30 ENTER
VERB 11 — запрос на отслеживание восьмеричных данных в первых регистрах трёх дисплеев модуля интерфейса дисплея и клавиатуры. NOUN 10 обозначал источник данных, которые надо было вывести — в данном случае, канал I/O. Последнее число, 30, обозначало номер одного из 17 каналов I/O, который команда желала посмотреть.
В 30-м канале содержалось несколько битов статуса, включая состояние инерционной платформы, дросселирование двигателя, и несколько индикаторов отказа. Однако самым главным битом была самая правая цифра дисплея: бит «отмена этапа спуска». И он был установлен.
Последствия этого были угрожающими. В данный момент ложный сигна
Habrahabr.ru прочитано 24691 раз
