Помните, в 2016 сотрудник NASA Крис Гарри опубликовал код миссии Apollo 11 на GitHub? Его можно изучать, загружать и изменять. Ну и, конечно, использовать для полета на Луну в собственных целях. Речь идет об исходниках кода командного модуля Comanche 055 и лунного модуля Luminary 099. Это «живой» код из 1969 года с комментариями инженеров.

Так вот. Если открыть этот проект сегодня, становится ясно, почему он до сих пор считается эталоном. Это живой пример настоящей инженерной школы, где каждое решение продиктовано жесткой практической необходимостью. Сегодня философия программирования изменилась, поэтому особенно интересно взглянуть на то, как изменился подход к написанию кода за 50+ лет.

Не спешите ругаться, что статья о коде Apollo 11 уже была на Хабре в далеком 2016. Тогда шуму наделал сам факт публикации легендарного проекта в открытом доступе. Сегодня, когда интерес к лунным миссиям разгорелся с новой силой, кажется уместным оценить успешный инженерный подход более чем полувековой давности.

Код был встроен в железо

Apollo Guidance Computer представлял собой специализированный бортовой вычислитель, спроектированный под конкретные задачи полета. У него была оперативная память на ферритовых сердечниках и постоянная память, реализованная по технологии прошивочных матриц (core rope). Вот только считали объем памяти тогда не в гигабайтах, а в словах. Например, объем оперативки составлял 2 048 слов, а постоянной — 36 864 слова (в пересчете на привычные единицы это около 70 килобайт). Процессор работал с тактовой частотой порядка 1 МГц и выполнял несколько десятков тысяч операций в секунду, чего хватало для непрерывного расчета ориентации, скорости и траектории.

Постоянную память нельзя было «записать» в привычном смысле — ее создавали вручную еще на этапе сборки. Программу буквально вплетали в железо: если провод проходит через магнитное кольцо, получается единица, если мимо — ноль. Такой метод делал систему невероятно живучей: ей были не страшны ни дикая вибрация при старте, ни космическая радиация, ни перепады температур. Но был и минус — код становился монолитом. После того как блок заливали защитным составом, изменить в программе нельзя было ни единого бита. Если в коде находили ошибку, приходилось заново переплетать весь модуль целиком.

Жесткие ограничения памяти и вычислительных ресурсов определяли всю архитектуру системы. Программа разбивалась на компактные подпрограммы, повторно использовала участки кода и максимально экономно расходовала каждый разряд. Для хранения данных применялись строго фиксированные области памяти, а структура программ подчинялась требованиям предсказуемости и детерминированности выполнения. Даже арифметические операции и работа с векторами оптимизировались на уровне отдельных инструкций, чтобы не тратить лишние машинные циклы.

Разработка велась с учетом того, что система должна работать в реальном времени и сохранять устойчивость при перегрузках. Программисты точно знали, какие участки кода выполняются чаще всего и сколько времени они занимают, и подстраивали логику под эти ограничения. В результате получилась система, способная одновременно выполнять навигационные расчеты, управлять ориентацией корабля и обрабатывать данные датчиков без сбоев. Именно такой подход обеспечил стабильную работу во время посадки, когда вычислительная нагрузка резко возросла, а ресурсы оставались прежними.

Планировщик задач умел жертвовать лишним

В основе системы лежал планировщик, который распределял задачи по строго заданным приоритетам. Каждой программе заранее назначался уровень важности, и вычислитель постоянно следил за тем, чтобы ключевые процессы получали ресурсы в первую очередь. Для хранения текущего состояния использовались так называемые core sets — фиксированные области памяти по 12 слов, а для расчетов с векторами выделялись отдельные рабочие области.

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

Сигналы с номерами 1201 и 1202 означали перегрузку вычислителя. Первый указывал на нехватку областей core sets, второй — на отсутствие свободных участков памяти для вычислений. Причина была в том, что радар сближения оставался активным в режиме перемещения. Его блоки формирования данных создавали поток прерываний, которые поступали на счетчики углов и отнимали процессорное время. В результате около 15% вычислительных ресурсов уходило на обработку лишних сигналов.

Несмотря на это, вычислитель продолжал выполнять основные задачи по управлению траекторией. Экипаж получил подтверждение, что посадку можно продолжать. Успех миссии во многом обеспечила именно такая организация работы: система не прекращала работу при перегрузке, а снижала объем второстепенных операций, сохраняя ресурсы для критически важных функций.

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Команды звучали как человеческий язык

Астронавты общались с бортовым компьютером через устройство DSKY — панель с небольшим цифровым дисплеем и кнопочной клавиатурой. Все управление строилось на оригинальной системе команд из двух чисел, которые называли «Глагол» и «Существительное». Первое число (Глагол) ставило задачу — что именно нужно сделать, а второе (Существительное) указывало на данные, к которым это действие относится. Например, одна комбинация цифр заставляла систему вывести на экран параметры работы двигателя, а другая — запускала сложный расчет сближения с другим модулем. Такой формат был предельно простым и исключал путаницу: каждой паре чисел соответствовала строго одна конкретная операция.

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

Такой способ управления создали инженеры лаборатории при MIT специально для условий пилотируемого космического полета. Главная цель была в том, чтобы человек мог мгновенно отдавать приказы и получать понятные ответы без лишних телодвижений. Эта логика прослеживается и в самом коде: все команды и их назначение прописаны максимально прозрачно. Программисты сделали все, чтобы полностью исключить любые двусмысленности, которые могли бы привести к ошибке в реальном времени.

А что сейчас

Маргарет Гамильтон, руководитель группы разработки бортового программного обеспечения Apollo в MIT, требовала, чтобы код был понятен, предсказуем и удобен для разбора в критических ситуациях. По сути, именно благодаря ее работе программирование в этом проекте стало восприниматься как строгая инженерная дисциплина, а не вспомогательная часть разработки.

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

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

Это особенно заметно в сложных инженерных проектах, включая космическую технику. На этапе испытаний подобные системы иногда ведут себя нестабильно, и выяснение причин занимает много времени именно из-за их внутренней сложности. В обычных условиях такие решения работают исправно, но при отклонении от штатных сценариев их поведение становится труднее предсказать.

На этом фоне особенно хорошо видны преимущества подхода, который использовался в Apollo. Ограниченные ресурсы заставляли концентрироваться только на необходимом и заранее продумывать архитектуру. Приоритеты задач, распределение ресурсов и поведение системы при перегрузке закладывались сразу, а не добавлялись позже. Это делало систему более предсказуемой и устойчивой в критических ситуациях.

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

История Apollo 11 хорошо показывает, что в критически важных задачах программирование — это полноценная инженерная работа, где важны не только функции, но и предсказуемость поведения. И в этом смысле опыт прошлого остается актуальным: даже при современных возможностях избыточная сложность может стать источником проблем.

Код по-прежнему доступен в открытом виде, и его можно изучить напрямую. Это редкая возможность увидеть, как строилась система, от которой зависел исход миссии, и понять, какие решения лежали в ее основе.