Законы космической инженерии (Законы Акина)

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

Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.

Ваши лучшие наработки в конечном итоге окажутся не нужны. Привыкайте жить с разочарованием.

Я как-то потратил несколько недель на оптимизацию кода, формирующего пакеты с телеметрией, с тем чтобы укорить его в несколько раз и сэкономить 10-15% общего времени выполнения. Что было очень важно, так как мы в очередной раз вылезли за допустимое время выполнения. Обложил юнит тестами со всех сторон… На code review основной претензией к коду было “ну я верю, что это работает, но нельзя ли как-нибудь попроще?” Через несколько недель я в отпуск пошел, а в том коде нашли баг… Было интересно и увлекательно.

А вот недавно, я просто удалил одну проверку в двух функциях, и сэкономил те же 10-15%. Результат одинаковый, но затраченные усилия отличаются на два порядка.

Ну и, само-собой, классика:

Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there’s no partial credit because most of the analysis was right…)

Космос совершенно не прощает ошибок. Если вы ошиблись при разработке - кто-то умрет (и вы не получите частичный зачет за то, что большая часть анализа была верной)

Список широко цитируется в узких кругах, в том числе на Хабре публиковался перевод (правда не на 100% точный, как мне кажется).

Нас обманывают!

P.S. Особенно доставляет то, что текст набран шрифтом Times New Roman (созданном в Великобритании) в Microsoft Word (созданном в США) на компьютере (разработанном в США и сделанном в Тайване), распечатан на лазерном принтере (неизвестной родословной, но опять же - разработан в США и сделан в Азии), а неопровержимые доказательства выложены на YouTube (созданном в США) с помощью сети Интернет (разработанной американскими учеными на деньги военных США). Справедливости ради замечу, что стена подъезда своя - отечественная.

Неделя удалась!

Не могу не отметить, что прошедшая неделя выдалась на удивленье урожайной.

Для начала, астрономам удалось объединить восемь наземных телескопов в один интерферометр размером с планету и сфотографировать черную дыру в ядре галактики M87 (в радиодиапазоне):

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

Далее, первый коммерческий запуск Falcon Heavy прошел как по маслу. Спутник выведен на нужную орбиту, все три ускорителя сели как положено, и даже створки обтекателя выловили из воды в хорошем состоянии:

К сожалению, первый частный лунный лендер не смог мягко прилуниться. В любом случае этот аппарат - заметный успех частной космонавтики. До сих пор частники до Луны еще не добирались:

И, наконец, вчера первый раз поднялся в воздух Stratolaunch:

Stratolaunch планируется использовать для запуска орбитальных ракет Pegasus II и Pegasus XL.

Южная Калифорния

Южную Калифорнию заливало дождями всю зиму. Ну по местным масштабам. Теперь все холмы цветут, жужжат и кишат всякой живностью. В Walker Canyon в одни выходные понаехало столько народу посмотреть на цветение маков, что тропу срочно закрыли. Мы умудрились проскочить за день до закрытия:

А сегодня мы ходили в Del Cerro Reserve. Таким зеленым мы его еще не видели:

В одном бите от ядерной катастрофы

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

Для начала светофором уже давно управляет автоматическая системы управления, задача которой - равномерно рассредоточить нагрузку на дорожную сеть. И хотя разгоняясь от предыдущего светофора вы, откровенно говоря, немного газанули (чтобы успеть до следующего красного), систему не дураки проектировали. Время переключения адаптируется в зависимости от времени суток и показаний датчиков, встроенный в полотно дороги. Шансов проскочить у вас не много.

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

Нажатие на тормоз все еще передается на колеса почти напрямую, но и этот бастион скоро падет.

Чем сложнее система, тем больше вероятность того, что человек не приминает никаких решений напрямую. В самолетах концепция fly-by-wire давно победила ручное управление. Ракеты изначально летают в полностью автоматическом режиме. Финансовые системы практически полностью существуют в виртуальном мире. Решения о покупке и продаже принимаются автоматически. Медицинская техника? Это только кажется, что человек нажимает кнопку и что-то при этом решает. На самом дале нажатие кнопки всего лишь запускает глючный код, который определяет дозу рентгена, которую получит пациент. Атомные станции? Ядерный арсенал? Управляется опытными операторами? Не смешите мои тапочки. Опытные операторы только кнопки нажимают. Компьютеры принимают все решения.

Как компьютер принимает решение? А вот так:

if (speed < desired_speed)
{
    accelerate();
}

Для процессора, который выполняет этот код, принятие решение выглядит как одна-единственная инструкция условного перехода. Если условие истинно, то перейти по этому адресу, я если нет - то по другому. Один бит.

Достаточно ошибится в одном бите, чтобы выполнить действие, прямо противоположное действие задуманному. Разница между “отдать штурвал от себя” и “потянуть штурвал на себя” - один бит.

Страшно?

Боинг 737 MAX

История с двумя авиакатастрофами самолетов Боинг 737 MAX 8 принимает интересный оборот. Эта модель самолета начала летать в мае 2017 года. 29 октября 2018 вскоре после взлета разбивается рейс 610 авиакомпании Lion Air. Далее, 10 марта 2019 года вскоре после взлета падает рейс 302 Эфиопских авиалиний.

Одинаковый характер обоих авиакатастроф ставит под подозрение систему MCAS (Maneuvering Characteristics Augmentation System) - новую систему разработанную специально для 737 MAX. Задача этой системы - избежать сваливания в ситуации, когда угол атаки превышает определенный порог. MCAS автоматически отклоняет горизонтальный стабилизатор, опуская нос самолета и уменьшая угол атаки.

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

Теперь выясняются интересные подробности. Во первых MCAS - это костыль который позволил Боингу сертифицировать 737 MAX не как совершенно новую модель самолета, а как модификацию существующей модели. 737 MAX оборудован новыми, большими по размеру двигателями, чем другие 373. Чтобы разместить новые двигатели под крыльями (без переделки фюзеляжа), их выдвинули вверх и вперед. Это в свою очередь изменило летные характеристики самолета и инженеры Боинга разработали MCAS, чтобы компенсировать разницу.

Почему нельзя было переделать фюзеляж? Можно было бы, но это был бы новый самолет, с более сложной программой сертификации. Учитывая, что 737 MAX нужен был для конкуренции с A320neo, то времени на разработку и сертификацию нового самолета не было (классика).

В принципе в идее MCAS нет ничего особенно плохого. Однако в данном случае по всей видимости произошло то, что называется “process miss” - а именно цепочка событий привела в двум катастрофам, причем каждое их этих событий само по себе к катастрофе бы не привело.

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

MCAS использует один (!) датчик угла атаки, который по всей видимости не достаточно надежен. На обоих самолетах были отмечены проблемы с этими датчиком. Боинг предлагает опцию (!), включающую установку второго сенсора и индикатора разногласий между датчиками. Оба самолета не были оборудованы этой опцией.

Далее, многие пилоты отметили неадекватное обучение при переходе на 737 MAX с 737. Боинг рекламировал самолет как обыкновенный 737-й, ничем значительным не отличающимся от “обычных” 737-х. Это похоже на явный неумышленный просчет. Я могу легко себе представить, что система “заставляющая 737 MAX вести себя как 737” могла проскочить, как не стоящая пристального внимания и переучивания пилотов.

Я уверен в этой цепочке еще с десяток разный событий. По настоящему мне странно только использование только одного датчика. Особенно для системы, которая срабатывает автоматически. По хорошему их должно быть три. Тогда выход из строя одного из датчиков не проблема. Два - немного хуже чем три. С двумя датчиками нельзя распознать некоторые сбои. Но один?

Скрытые угрозы

Ой, други мои! Ржу, не могу остановится. Текут слезы и болят бока. Набрел на шедевр махровой пропаганды, или как говорят в теперешней России, - вторник. Смотрите сами, а главное, - до самого конца:

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

Не реалистично.

Знаете как выглядят настоящие двухминутки ненависти? Это когда посмотрят такой вот продукт и говорят “пропаганда и вранье, конечно, но вот одну вещь они правильно заметили…”

Водоплавающая ступень

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

С первых моментов закрутки стало ясно, что дело пахнет керосином. Зрители сразу заметно оживились. Первая оформившаяся мысль была: “Ух ты! Смотри как она может”. Следующая за ней: “Интересно, когда рванет?” При посадке ступень сначала целится в океан - мимо посадочной площадки. Как раз на случай если, что пойдет не так. Так что особых переживаний, что она кому-то на голову упадет не было. Просто было интересно чем все закончится.

Закончилось все не так, как можно было бы ожидать. Ступень погасила скорость, выпустила ноги, и мягко приводнилась. Что самое интересное, степень не взорвалась когда ожидаемо завалилась на бок. Более того, изображение не пропало до самого конца - что означает, что передатчик и авионика продолжала работать как ни в чем не бывало.

Еще одно видео:

P.S. Dragon без приключений вышел на запланированную орбиту.

Как выглядит запуск с орбиты

Впечатляющее видео - покадровая съемка, показывающая как выглядел запуск Прогресса MC-10 с борта МКС:

Волшебство Питона

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

Непонятно как все это счастье держать в одной куче. Неужели все живут за счет 100% покрытия тестами? Не верю. Или все на PyCharm сидят?

Расскажу про очередной прикол Питона. Итак есть простой код:

def init(factories):
    """Convert a list of factorie into a list of objects.""" 
    return [factory() for factory in factories]

def cleanup(objects):
    """Clean up objects in the reversed order of their creation."""
    for obj in reversed(objects):
        obj.cleanup()

init() берет список фабрик и отдает список объектов, созданных фабриками. cleanup() чистит созданные объекты в порядке, противоположном порядку создания. Нам требуется написать тест, который проверяет, что методы cleanup() вызываются в правильном порядке:

from itertools import permutations
import mock

def test_cleanup():
    """Verify cleanup() order."""
    # Try all permitations of initialization order. 
    for init_order in permutations(range(3)):
        cleanup_order = []

        def factory(index):
            def cleanup():
                """Record the clean up order."""
                cleanup_order.append(index)

            def create():
                """Return a mock implementing cleanup()."""
                obj = mock.Mock
                obj.cleanup = mock.Mock(side_effect=cleanup)
                return obj

            return create

        # Create objects in the desired order.
        objects = init([factory(index) for index in init_order])

        cleanup(objects)

        # Verify that the object were cleaned up in the reveresed
        # order of their creation.
        assert cleanup_order == list(reversed(init_order))

Разберу логику по кускам. Тест перебирает все возможные кобинации порядка создания объектов:

for init_order in permutations(range(3)):

Декоратор factory() возвращает фабрику create(), которая в свою учередь создает объект с методом cleanup(). Для создания объекта на коленке используется Mock. Релизация cleanup() запоминает порядок вызова в cleanup_order.

init() создает объекты в заданном порядке, cleanup() - чистит:

objects = init([factory(index) for index in init_order])

cleanup(objects)

Наконец, в самом конце мы проверяем, что порядок очистки противоположен порядку создания:

assert cleanup_order == list(reversed(init_order))

Все просто, не так ли? Запускаем тест и получаем облом:

>               assert cleanup_order == list(reversed(init_order))
E     assert [2, 2, 2] == [2, 1, 0]
E       At index 1 diff: 2 != 1
E       Use -v to get the full diff


rabbit_test.py:41: AssertionError 

Заядлые питонщики давно раскусили, в чем проблема. А вы сможете найти ошибку не заглядывая в ответ?