CBunny

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

Производство электроники для Apollo стало первым массовым заказом интегральных схем в истории: в 63 году на нужды программы шло 60% всех выпускаемых микросхем. Этот заказ превратил Fairchild Semiconductor (будущего «родителя» Intel) из стартапа в крупнейшего производителя микроэлектроники своего времени, с большим отрывом обгоняя Texas Instruments.

Сначала интегральные схемы не казались привлекательной технологией: они были значительно дороже дискретных компонентов, а в их надёжности сомневались даже инженеры. Массовый государственный заказ сделал возможным приток инвестиций и снижение себестоимости. А успех Аполлона и безотказная работа электроники в суровых космических условиях стали лучшей рекламой. Без этого массовая микроэлектроника появилась бы в мире гораздо позже.

Так начиналась новая эпоха — не только в железе, но и в программировании. Термин software engineering вошел в обиход, именно благодаря Маргарет Гамильтон, руководившей разработкой ПО для AGC и стремившейся подчеркнуть, что программирование — это полноценная и самостоятельная инженерная дисциплина.

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

Для управления столь сложной миссией потребовалось немало электроники — по меркам своего времени. Сложные вычислительные блоки были в каждом компоненте программы Аполлон: Launch Vehicle Digital Computer (LVDC) — в ракете-носителе Saturn V, Apollo Guidance Computer (AGC) — в командном и лунном модулях, с разными программами для каждого. На случай аварийной ситуации в лунном модуле предусматривалась резервная система — Abort Guidance System (AGS), задачей которой было лишь одно: вернуть астронавтов домой.

Ну а теперь — обо всём по порядку.

Saturn V, или самая большая пороховая бочка в истории

Всё управление этой трёхступенчатой махиной высотой с 36-этажный дом было сосредоточено в кольцевом отсеке третьей ступени — Instrument Unit. Мозгом ракеты служил Launch Vehicle Digital Computer (LVDC), связанный с другими системами через адаптер LVDA. Он координировал работу с:

• инерциальными сенсорами ST-124 (IMU)

• отдельным аналоговым Flight Control Computer (FCC) — управлявшим вектором тяги

• радиокоммуникационной системой для приёма команд с Земли

• пиропатронами, разделяющими ступени в нужный момент

Если LVDC был мозгом ракеты, то FCC — её вестибулярный аппарат. Полностью аналоговый, исключительно надёжный вычислитель, отвечавший за ориентацию ракеты и управление вектором тяги. Для отказоустойчивости он был реализован с тройной избыточностью: три параллельных канала выполняли одни и те же расчёты, а результат выбирался по принципу мажоритарного голосования — по совпадению двух из трёх сигналов.

Независимо от основного компьютера работала система аварийного спасения (Emergency Detection System, EDS). Её задача — мгновенно реагировать на критические отклонения ракеты и запуск системы спасения экипажа.

Launch Vehicle Digital Computer (LVDC)

Компьютер, управлявший всеми этапами полёта ракеты, представлял собой «бутерброд» из трёх блоков: логического, памяти и адаптера ввода-вывода (LVDA), соединённых в герметичном корпусе (у LVDA был собственный корпус). При всей своей важности по производительности он едва дотягивал до Arduino, а весил при этом 214 фунтов (97,1 кг) и потреблял 137 Вт.

Блок логики выглядел как «серверная стойка» из 18 × 5 = 90 функциональных модулей (Page Assembly). Все модули делились на пять групп (каналов): 1, 2 и 3 — полностью идентичные для тройной избыточности, 4 и 5 — вспомогательная логика ввода-вывода и принятия решений (Disagreement Detectors, DD).

Каждый Page Assembly состоял из до 30 Unit Logic Devices (ULD) — небольших керамических модулей размером 7,6 × 8 мм, каждый из которых содержал один логический элемент (стандартную «ячейку», если угодно) на четырёх кремниевых кристаллах с прецизионными толстоплёночными резисторами. Всего применялся 51 тип таких элементов. Разработанные IBM специально для космоса, ULD отличались высокой надёжностью, точностью и возможностью модульной замены, в отличии от ранних интегральных схем.

К сожалению, до нас дошла лишь часть документации по LVDC — в частности, почти нет сведений о том, как IBM производила ULD, только высокоуровневые отчёты. Поэтому энтузиасты занимаются реверс-инжинирингом логики LVDC.

Saturn V Launch Vehicle Digital Computer (LVDC) Circuit Board

LVDC поддерживал до восьми модулей ферритовой памяти, каждый ёмкостью 4096 слов по 28 бит (26 бит данных + 2 бита чётности). Максимальная конфигурация давала 32 768 слов — примерно 96 КБ.

Каждый модуль весил около 5 фунтов (2,3 кг) и содержал стек из 14 плоскостей ферритовых колец размером 128 × 64 ячейки, вместе с вспомогтальеной логикой (для выбора нужной ячейки) и усилителей сигналов.

Через каждое кольцо диаметром 0,8 мм вручную протягивались четыре провода: X, Y, Sense и Inhibit. Всего в одном модуле насчитывалось 114 688 колец.

Очень подробно про устройство и функционирование модулей памяти LVDC и русский перевод.

Программы для LVDC до нас дошли тоже не все, точнее способ написания прогррамы для LVDC сильно отличался и поэтому у нас есть только набор отрывков для разных миссий. В отличие от AGC, где весь код был единым целым, в LVDC программы были модульными, с соглашением по какому адресу находятся «интерфейсы» того или иного модуля. Разработчик модуля мог никогда не видеть кода другого модуля и не представлять как он работал. Подчерк IBM — подход к проектированию ПО, повторяет модульный подход к проектированию железа.

Pings из космоса

Вся электронная часть кокпита лунного и командного модулей называлась: Primary Guidance, Navigation, and Control System (PGNCS), произносилась — пингс 🙃

Она включала:

• коммуникационные VHF-транспондеры и приёмо-передатчики телеметрии

• систему радаров

• инерциальную навигационную систему (IMU): акселерометр и оптический звездный навигатор

• управление двигателями и системой ориентации (RCS)

• навигационную панель с необходимой информацией

• клавиатуру и дисплей — Display and Keyboard (DSKY), произносилось —DIS-kee

В центре всего этого находился и управлял всем — Apollo Guidance Computer (AGC).

Компьютером был цельнометаллический блок весом 32 кг, который крепился к плите с водяным охлаждением (обычная космическая практика) и «пользовательский интерфейс» — Display and Keyboard (DSKY), который представлял собой цифровую клавиатуру и электролюминесцентные 7-сегментные 5-разрядные индикаторы.

Астронавты вводили команды с помощью цифровых кодов в последовательности «глагол (verb) – существительное (noun)», например «отобразить скорость». Пятиразрядные дисплеи показывали значения трёх регистров — в десятичном формате со знаком ± или в восьмеричном без знака. Такой богатый интерфейс и астронавты должны были знать все команды, параметры и программы наизусть.

Подробный отчёт [pdf] о внутреннем устройстве DSKY и инструкции по воссозданию реплики. Документация NASA по командам и индикации интерфейса.

Внутренне AGC представлял собой два блока из заменяемых модулей. Первоначально сомневались в надёжности интегральных схем, поэтому требовалась заменяемость и ремонтопригодность — предполагалось, что астронавты смогут проводить замену прямо в космосе (например, из двух AGC собрать один 🙂). Впоследствии это требование из ТЗ убрали.

Верхний блок был блоком памяти: справа располагался 72КБ ROM, чёрные модули — 4КБ RAM, остальное — служебные драйверы памяти. Нижний блок содержал логику и интерфейс ввода-вывода.

Для AGC потребовалось 4100 NOR-вентилей, 3 000 интегральных схем и 17 000 транзисторов. Это составляло 60% всех интегральных схем, произведённых в США в период с 1962 по 1967 год. При тактовой частоте 1 МГц (внешний источник — 2 МГц) его производительность достигала 14 245 операций с плавающей точкой в секунду (FLOPS), при энергопотреблении 55 Вт. Для сравнения, более тяжёлый и энергоёмкий LVDC (в 2,5-3 раза по весу и потреблению) выполнял 12 190 инструкций в секунду.

Отчасти это стало возможным благодаря миниатюризации интегральных схем, а отчасти — использованию неизменяемой памяти (ROM), которую прошивали вручную. Процесс занимал около восьми недель машинно-ручного труда. Для этого была создана специальная «швейная машина», которая считывала данные с перфоленты и точно позиционировала ферритовое кольцо. Затем вручную через каждое кольцо продевали 192 провода считывания (sense wires), кодируя единицу, или обходили кольцо — кодируя ноль. Эта обеспечивало самую высокую плотность хранения данных того времени.

Abort Guidance System (AGS)

Лунный модуль отличался от командного тем, что кроме основного AGC в нём был второй резервный компьютер — Abort Guidance System (AGS), предназначенный для аварийных ситуаций. Забавно, что изначально AGS называлась «Backup Guidance System» (резервная система навигации), но её аббревиатуру (BUGS) сочли слишком неудачной.

AGS был полностью независимым компьютером, напрямую связанным с инерциальной навигационной системой (IMU), двигателями и датчиками аварийной системы — Abort Sensor Assembly (ASA). А для взаимодействия с экипажем он имел собственный интерфейс ввода-вывода — Data Entry and Display Assembly (DEDA).

Разрабатывался он также независимо — в итоге каждая вычислительная система имела собственную архитектуру и проектировалась разными организациями:

• LVDC — IBM

• AGC — MIT Instrumentation Lab

• AGS — TRW

Во время Apollo-10 AGS чуть не привёл к аварии при сближении с Луной — из-за ошибки в процедурах экипажа. В этой миссии посадка не планировалась, проводилось лишь тестирование полёта лунного модуля. На высоте около 100 м над поверхностью командир Том Стаффорд по ошибке переключил AGS в режим «наведение на CM» вместо «удержания ориентации», из-за чего система резко развернула LM в сторону командного модуля.

Понять скромные масштабы модулей, в которых жили астронавты, можно по тренажёру: здесь в центре виден DSKY, а правее его, рядом с джойстиком — DEDA.

Наследие

Хотя эпоха «Аполлонов» давно осталась в прошлом, но её наследие сегодня выливается во множество хобби и образовательных проектов.

Восстановление оригинального AGC

Apollo Guidance Computer Restoration (43 videos)

Marc Verdiell: Restoring the Apollo Guidance Computer

Virtual AGC

С 2003 года энтузиасты собирают и оцифровывают документацию, схемы и исходный код для компьютеров «Аполлона». Благодаря этому сегодня можно запустить в эмуляторе оригинальные программы миссий — от Apollo 7 до Apollo 17. Для AGC есть даже verilog модель всей логики (привет FPGA версии). Это используют для обучения будущих инженеров, интеграции в игры и 3D-симуляции и просто экспериментов. Исходники и вся документация на GitHub проекта. И конечно вселенная не может существовать без версии на Rust 🙂

DSKY реплики

DIY-сообщество создало множество проектов по воссозданию DSKY — в первую очередь потому, что их можно подключить к Virtual AGC и по-настоящему «полетать» на «Аполлоне»:

• Реплика на Raspberry Pi с эмулятором yaAGC — компактный и доступный вариант для домашнего стенда.

• DSKY-matic — максимально близкий к оригиналу по внешнему виду.

• Реплика с электролюминесцентным дисплеем — с тем самым мягким «зелёным» свечением, как в 60-е.

• Механически точная копия DSKY — повторяет конструкцию оригинала вплоть до механики клавиш.

А ещё кто-то выпустил наручные часы в виде DSKY.

Apollo 11 VR

В Steam есть симулятор Apollo 11 в VR, позволяющий пережить миссию от старта до посадки на Луну. А что будет если к ней подключить Virtual AGC и реалистичную физику?

via

Нашел интересный пост про новый двигатели Raptor:

Некоторое время назад в Starbase прошёл тест со срабатыванием запальников двигателей Раптор 3 на первой ступени третьей версии Старшипа

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

Если вкратце - на самых первых демонстраторах двигателя Раптор стояла отработанная и вполне понятная система зажигания для американского ракетного двигателестроения - 2 компонента, триэтилалюминий и триэтилборан - подаются в небольшую камеру сгорания, где воспламеняются при контакте, и горячие продукты сгорания уже поджигали компоненты в газогенераторах и в главной камере сгорания. Это так называемая химическая система зажигания. Точно такая же система стоит двигателях РД-170, на Merlin-1D+ и многих других. Зелёная вспышка при запуске этих двигателей - следствие присутствия ионов бора в пламени. Основной её минус - компоненты токсичные, очень опасные в работе (в том числе, самовоспламеняются на воздухе), и если двигатель выработал запас пускового топлива - перезапустить его без перезарядки просто невозможно.

Решение есть. Все просто - есть 2 электрода, на них подаётся высокое напряжение, между ними пробивает искра/дуговой разряд, и теплота от этого события поджигает топливные компоненты. Это искровой запальник. Чтобы не ставить такой запальник в самое пекло, делается отдельная небольшая камера сгорания, где компоненты подаются при некотором другом соотношении, позволяя поджечься, но не горя при таких же высоких температурах, как в камере сгорания. И уже этот выхлоп из запальника идёт куда нужно. Это уже факельный запальник.

Такие запальники стоят например на RS-25 (главные двигатели Шаттла), на RL-10 (двигатели РБ Centaur), и их начали ставить уже в 2016-2018 годах на прототипы Рапторов, так же как и продолжили их ставить на Рапторы 1 и 2.

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

Но на Рапторе 3 очень незаметно, была внедрена, судя по всему, уникальная для ракетного двигателестроения система зажигания

Термоакустические (резонансные) запальники

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

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

Идея, в общем то, не нова. Еще в 1971 году, исследователи NASA продемонстрировали резонансный запальник, который зажигался на водород-кислороде всего за 0.13 секунд при давлении подачи всего 2.4 атмосферы.

В 2018 году в Техническом университете Мюнхена сделали прототип метан-кислородного резонансного запальника. Так как такая смесь обладает большей средней молекулярной массой, то и скорость звука там ниже, поэтому добиться зажигания тяжело. Но в итоге смогли достичь стабильный запуск, сначала 4 секунды продувая кислородом при 2 МПа, прогревая резонансную полость, а затем впрыскивая метан, который поджигался за 150 мсек

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

Если характерное завывание сегодняшнего теста действительно от резонансного нутра новых запальников - это, без шуток, прорыв. Полностью пассивный, лёгкий, многоразовый запальник, без высоковольтных источников. Красота!

via

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

В этой статье речь пойдёт о нескольких ярких случаях, когда сбои ПО серьёзно отразились на подобных критических средах, в которых ошибки недопустимы.

▍ ✈️ Кейс 1. Авария ракеты-носителя «Ариан-5»

Четвёртого июня 1996 года Европейское космическое агентство (European Space Agency, ESA) впервые запустило ракету «Ариан 5», отметив важный момент в истории исследования космоса. Однако миссия оказалась провальной, поскольку буквально одна строка кода привела к катастрофическому сбою и потере всего груза стоимостью почти полмиллиарда евро.

Ракета «Ариан 5» (фр. Ariane 5)

Эта ракета должна была доставить два спутника связи на геостационарную переходную орбиту. Запуск шёл гладко, пока ракета не отклонилась от траектории и не разрушилась на 37 секунде полёта. Было установлено, что причиной катастрофы стал программный сбой в системе наведения, которая отвечала за регулирование курса полёта ракеты. Сбой при запуске Ариан-5 был признан одним из самых дорогостоящих в истории ПО. Разрушение научных спутников привело к задержке исследований магнитосферы Земли почти на 4 года.

В чём же была причина? Мёртвая часть кода программы из последней миссии Ариан-4, которая стартовала примерно 10 годами ранее, содержала простую и вполне исправимую ошибку. Ракета определяла свою направленность движения вверх или вниз с помощью метода, известного как горизонтальное смещение, иногда также называемого «BH value». Его значение представлялось 64-битной переменной с плавающей запятой, которую система наведения использовала для преобразования в 16 16-битных знаковых целых. 64-битная переменная может представлять миллиарды значений, в то время как 16-битная может выражать лишь 65 535.

Нам известно, что в целых числах первый бит представляет знак, и что 16-битные целые могут находиться в диапазоне от -32 768 до 32 767. При этом числа с плавающей запятой создаются для отслеживания более широкого диапазона значений, используя то же количество битов между -1.8e+308 и -2.2e-308. Если вы попытаетесь сохранить такое значение в 16-битном целом числе, то оно значительно выйдет за его допустимые границы. По итогу в программном обеспечении ракеты произошло хорошо известное целочисленное переполнение.

Катастрофе поспособствовал и ещё один фактор, а именно требование операторов, чтобы Ариан-5 летела по значительно более крутой траектории в сравнении с предыдущими ракетами, что привело к невероятной высокой скорости вертикального движения.

Какие ключевые выводы можно сделать из этой катастрофы?

• Копирование кода без его понимания (карго-культ) представляет серьёзную проблему.

• Ещё одна проблема — это отсутствие подобающей обработки ошибок.

• Пренебрежение изменениями, внесёнными по требованию операторов, и

• Отсутствие необходимого тестирования.

В итоге комиссия по расследованию составила следующие рекомендации:

• R1 — избегать использования программ или систем, которые не являются обязательными. Во время полёта программное обеспечение не должно выполняться, если на то нет необходимости.

• R2, R10, R11 — критически необходимо проводить тестирование. Организуйте тестовую среду с максимальным объёмом тестового оборудования и проводите тщательное тестирование системы в закрытом цикле. Всем миссиям должны предшествовать полноценно реализованные симуляции с обширным покрытием тестами.

• R4 — проводить код-ревью. В любом языке программирования важны все детали кода.

• R6, R8 и R13 — необходимо повышать читаемость за счёт обработки исключений в задачах и создания резервных механизмов для поддержания стабильной работы во время сбоев. При определении критических компонентов важно также учитывать возможные программные сбои. Организуйте команду для выработки строгих правил тестирования ПО, обеспечивающих следование высококачественным стандартам.

Информационные ссылки:
Ariane 5: Flight 501 failure — Report by the Inquiry Board (версия HTML).
Ariane 5: A programming problem? Широкое обсуждение программного сбоя миссии Ариан-5.

▍ ✈️ Кейс 2. Как неперехваченное SQLException остановило работу авиалиний

В январе 2023 года агентство Reuters поведало об интересном инциденте, произошедшем в Федеральном управлении гражданской авиации (Federal Aviation Administration, FAA). В ходе анализа происшествия специалисты управления выяснили, что работающий по контракту специалист «непреднамеренно удалил файлы», вызвав общенациональный запрет на вылеты 11 января. Если говорить точнее, в тот день оказалось отменено более 11 000 полётов. Представители управления сообщили, что этот сотрудник работал над синхронизацией основной и резервной баз данных.

Это напоминает мне о проблеме, о которой рассказывается в главе 2 книги «Release It» Майкла Найгарда. Авиалинии планировали произвести аварийное переключение кластера базы данных, выступавшего основной системой, выстроенной по принципу сервис-ориентированной архитектуры. Этот поэтапный переход был запланирован и распределён по функциональности. Названная система обрабатывала поиск, возвращая для разных запросов (дата, время, город) детали перелётов.

Программное обеспечение авиалинии работало на кластере прикладных серверов J2EE с БД Oracle, обеспечивавшей резервную избыточность данных, и аналогичными аппаратными балансировщиками нагрузки, которые на тот момент представляли распространённую высоконадёжную архитектуру. Однажды инженеры выполнили ручной аварийный переход с Database 1 на Database 2 (первый резерв). Они проделывали это много раз, и всё прошло в точности, как планировалось. Затем, спустя 2 часа, система перестала обслуживать запросы, отображавшиеся на их интерактивных терминалах. После некоторого анализа они решили перезапустить приложения, что привело к проблеме, остановив работу авиалиний примерно на 3 часа.

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

Что ещё они могли предпринять в этой ситуации? Невозможно предотвратить все ошибки. Некоторые баги неизбежны. Мы лишь можем предотвратить влияние ошибок одной системы на другую.

▍ ✈️ Кейс 3. Катастрофа Boeing 737 MAX

В октябре 2018 и марте 2019 года потерпели крушение два Boeing 737 MAX, в результате чего погибло 364 человека. Отчасти причиной этого стала программная система, созданная для повышения безопасности полётов.

MCAS — Maneuvering Characteristics Augmentation System (система повышения манёвренности самолёта) — стала камнем преткновения в истории с Boeing 737 MAX. Созданное из необходимости, это программное обеспечение стало решением внутреннего недочёта дизайна (а именно программным исправлением аппаратной проблемы [1]). Модель 737 MAX, оснащённая расширенными, более экономичными по топливу двигателями, имела иные аэродинамические свойства, нежели её предшественники. MCAS должна была позволить этой модели обрабатывать те же нагрузки, что обрабатывали прежние модели линейки 737, при этом обеспечивая лёгкую адаптацию пилотов к новшеству.

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

Критический недочёт? MCAS опиралась на вводные данные лишь одного из двух датчиков угла атаки (angle of attack, ATA) самолёта [2], [3]. В случае передачи этим датчиком некорректных данных произошло бы ложное срабатывание MCAS, что привело бы к наклону носа самолёта вниз даже тогда, когда это не нужно. Дополнительно усложняя проблему, система бы срабатывала повторно, потенциально вводя в недоумение пилотов, которые не были в должной степени осведомлены о её существовании или поведении.

Установив более крупный двигатель, компания Boeing изменила аэродинамические характеристики модели 737. (Источник: NOREBBO.COM)

Однако история про MCAS не будет завершённой без освещения фактов, которые вскрылись после крушений. Впоследствии было заявлено, что компания Boeing поручила значительную часть разработки ПО для модели 737 MAX сторонним инженерам, которым платили всего по $9/час [4]. Как сообщили бывшие инженеры ПО этой компании, она всё больше начинала полагаться на временных сотрудников, в частности, недавних выпускников колледжей, услуги которых предоставляли зарубежные центры разработки ПО. Это решение, скорее всего принятое в свете необходимости сокращения расходов и ускорения разработки, привносит ещё один уровень сложности в историю про Boeing 737 MAX.

Что мы можем почерпнуть из этой истории как инженеры ПО:

1. Исключайте единую точку отказа. Случай с MCAS является острым напоминанием о важности наличия в критических системах резервных решений. Использование в качестве ориентира единственного источника данных — в описанном случае датчика AOA — создало уязвимость, которая привела к катастрофическим последствиям. В нашей работе мы всегда должны задаваться вопросом: «Что произойдёт, если этот компонент даст сбой?»

2. Делайте ПО и системы простыми, но не слишком простыми (принцип KISS, Keep it simple, stupid). Система MCAS стала ярким примером оверинжиниринга решения аппаратной проблемы. Вместо того чтобы устранить внутреннюю нестабильность в дизайне 737 MAX, компания Boeing решила прибегнуть к программному «исправлению», которое внесло новые уязвимости.

3. Отсутствие предметного опыта. Многие инженеры, нанимаемые через сторонние организации, не обладают достаточным опытом в сфере аэрокосмических технологий и критических к безопасности систем. Это привело к проблемам в коммуникации и ошибкам, которые потребовали неоднократных корректировок.

4. Слабое тестирование. Несмотря на обширное тестирование, фатальные сбои в MCAS не были обнаружены, пока самолёты не поступали на обслуживание. Это поднимает важные вопросы об адекватности текущего тестирования и практик симуляции, особенно для систем, в которых реальные условия сложно воссоздать полноценно.

Что мы, как программные инженеры, можем сделать для решения перечисленных проблем? Вот некоторые мысли по этому поводу:

• Реализовать подобающую обработку ошибок. Проектируйте свои системы с учётом того, что их компоненты будут давать сбой. Реализуйте резервные механизмы, перекрёстные проверки и предохранительные меры.

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

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

• Развивать культуру открытого взаимодействия. Создайте среду, в которой люди смогут безбоязненно высказывать свои беспокойства, а аварийные ситуации будут рассматриваться как ценные уроки, а не что-то постыдное, что хочется поскорее замять.

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

▍ Ссылки

[1] “How the Boeing 737 Max disaster looks to a software developer”, Gregory Travis, IEEE Spectrum, 2019.↪
[2] “Killer software: 4 lessons from the deadly 737 MAX crashes”, Matt Hamblen.↪
[3] “Eight lines of code could have saved 346 lives in Boeing 737 MAX crashes, expert says.” Matt Hamblen↪
[4] “Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers“, Bloomberg, 2019.↪
[5] “The Boeing 737 MAX: Lessons for Engineering Ethics”, Herket J. et al., Sci Eng Ethics. 2020.

Перевод

Источник

Журналист Эрик Бергер поделился подробностями плана Blue Origin по ускорению первой лунной высадки в рамках программы Artemis. Заголовок выше кратко описывает архитектуру этой задумки.

Итак, есть 2 типа миссий.

Беспилотный тест:

- Для этой архитектуры необходимо 3 запуска ракеты New Glenn;
- Первые 2 пуска выводят по одному разгонному блоку на низкую околоземную орбиту;
- Третий запуск выводит аппарат Blue Moon MK2-IL (уменьшенная версия MK2 на базе MK1);
- Все 3 части стыкуются на опорной орбите в одну систему;
- Затем первый разгонный блок выводит 2 других части на высокоэллиптическую орбиту (позже сгорает в атмосфере);
- Затем второй разгонный блок выводит MK2-IL на замкнутую орбиту вокруг Луны (15 на 100км);
- С этой орбиты MK2-IL проводит посадку, а затем и демонстрация взлёта с поверхности Луны.

Ускоренная пилотируемая миссия:
- Для этой архитектуры необходимо уже 4 запуска ракеты New Glenn;
- Первые 3 пуска выводят по одному разгонному блоку на низкую околоземную орбиту;
- Четвёртый запуск выводит аппарат Blue Moon MK2-IL (уменьшенная версия MK2 на базе MK1);
- Все 4 части стыкуются на опорной орбите в одну систему;
- Затем первый разгонный блок выводит 3 других части на эллиптическую орбиту;
- Затем второй разгонный блок доводит до лунной прямолинейной гало-орбите (в этом плане NRHO присутствует) и там же стыкуется с Orion;
- Затем экипаж перебирается в MK2-IL и начинает спуск с помощью третьего разгонного блока на низкую лунную орбиту;
- После этого посадка, экспедиция, взлёт и стыковка с Orion.

Бергер также уточняет, что у него нет информации по конструкции разгонного блока от Blue Origin, и построен ли он на базе системы Transporter, а также как выглядит MK2-IL и является ли он адаптированной версией MK1 (друзья канала утверждают, что да).

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

Сам план чуть проще того, который необходим для Starship HLS с двумя полными перезаправками на двух орбитах или требований для Blue Moon MK2, но даже эта архитектура сложнее текущего плана в китайской лунной программе — там для высадки требуется всего 2 запуска.

via