Тестировать больше и лучше: Закончился разбор аварийного полета Boeing Starliner +35



NASA и Boeing закончили анализ декабрьского полета Boeing Starliner. Напомню, в первом беспилотном испытательном пуске нового корабля программу полета получилось выполнить только частично, сорвалась стыковка с МКС, продолжительность миссии пришлось сократить до двух суток, и при этом корабль дважды едва не был потерян окончательно. Отчет не опубликован полностью, но известно, что 80 рекомендаций в очередной раз подчеркивают важность тщательного и качественного тестирования.


Послеполетное обслуживание Boeing Starliner, фото NASA/Bill Ingalls

Дважды почти потерянный


По терминологии NASA миссию признали «почти потерянной с широким освещением СМИ» («high visibility close call»). Следующий за этим термин — авария с потерей корабля и, возможно, гибелью людей. Статус довольно редкий, и в последний раз так обозначили ситуацию, когда в 2013 астронавт Лука Пармитано на выходе в открытый космос чуть не утонул прямо в скафандре из-за забитого фильтра системы водяного охлаждения.

Первый баг проявил себя спустя 31 минуту после старта. Корабль не выполнил ожидаемый маневр по переходу на траекторию перелета к МКС с исходной орбиты. ЦУП попытался исправить ситуацию, но, как на зло, на эти попытки наложились проблемы со связью, и в итоге Starliner оказался на орбите, непригодной для сближения с МКС, и пустыми топливными баками. Из-за ошибки в коде корабль синхронизировал с ракетой-носителем таймер полетного времени не в момент начала обратного отсчета, а за 11 часов до пуска. В результате бортовой компьютер считал, что корабль находится на другом этапе полета, нежели это было в реальности.


Разделение отсеков корабля Staliner, кадр из видео Boeing

Второй баг проявить себя не успел. Из-за первой проблемы специалисты NASA и Boeing стали анализировать код на предмет «а не пропустили ли мы еще что-нибудь?» И, как оказалось, не зря. В процессе посадки, после выполнения тормозного маневра, корабль должен был разделиться на спускаемый аппарат и сервисный модуль (показан на иллюстрации выше, подобную процедуру проходят почти все космические корабли, например, «Союз» разделяется на три отсека, а Crew Draron сбрасывает сервисный модуль перед торможением). После отделения, сервисный модуль должен был выполнить маневр по уходу в сторону от корабля, но из-за ошибки в коде порядок действий неправильно передавался в управляющий процессом контроллер. В результате сервисный модуль мог удариться о спускаемый аппарат и натворить там бед.

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

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

Что делать?


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

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

10 рекомендаций отнесли к требованиям, но по сути они тоже относятся к тестированию. Требования с многочисленными условиями должны лучше анализироваться и необходимо повышать decision coverage — покрытие тестами условий в программном коде. Напомню, что 100% decision coverage означает 100% statement coverage, но не наоборот.

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

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

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

Дорогой урок


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




Комментарии (16):

  1. DrPass
    /#21839522 / +17

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

    • striver
      /#21840424

      Если это дешево, то что будет дороже? В раза 2 дороже, чем то, что делают СпейсЭкс?

      • Viceroyalty
        /#21850698

        Возможно, просто у бюрократизированной огромной компании, которой много лет издержки на создание нового выше чем у относительно свежей и небольшой — как у Rust и C++. При этом не говорю что Boieng или C++ это плохо, но, возможно, для некоторых новых вещей Boieng нужны нишевые дочки

    • selivanov_pavel
      /#21840530 / +9

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


      Результаты налицо — падающий обновлённый 737, теперь вот не долетающий до орбиты старлайнер.

      • Javian
        /#21841662 / +6

        «Никто не хочет брать новые самолеты», но менеджеры верят в продажи.

        Boeing is scrambling to shore up financing for the 737 MAX as it awaits regulatory approval for design changes after the plane was grounded following two fatal crashes, industry sources said.
        ***
        “Nobody wants to take new aircraft and this is particularly true for the MAX right now,” a senior aviation financier said.

        Boeing in scramble to shore up 737 MAX financing

      • clawham
        /#21843662 / +3

        Справедливости ради максы не сами падают и впринципе да… небольшой грешок за програмистами по выбору «верного» датчика есть но по факту отказ этой системы изза отказа датчика приходится как минимум на три бюлетеня о IAS DISAGREE согласно которого выполнив все пункты можно спокойно было как минимум вернуться на взлетный аэропорт и как максимум — долететь некоторым дискомфортом. Кроме того сразу после первого неразбившегося(пилоты распознали IAS DISAGREE и выполнив бюлетень смогли посадить самолет) боинг выпустил расширенный бюлетень по МКАС выполняя полностью который можно было спокойно продолжать полет!
        Тут проблема сильно комплексная была. И пилоты которым запрещено вручную летать — они изза этого потеряли навыки, и обучалка которая натаскивает на типовые редкослучаемые аварии вроде разгерметизации или отказа двигателя но не одновременное выпадание обоих аварий, и сертификация самолетов где могут проскочить неявные баги в логике постановки задачи — датчиков два есть автомат выбора какой датчик правильно показывает и есть ручное управление выбором какому датчику верить но не все системы используют именно результирующий выбранный автоматикой или вручную верно показывающий датчик тангажа и прочие прочие прочие чисто организационные проблемы.
        Конечно легко скинуть вину на програмиста-индуса и вуаля все белые и пушистые но после первого аварийного случая с успешной посадкой все летчики максов активно обсуждали именно этот случай и только ленивые не прорабатывали в голове эту же самую ситуацию и свои действия в случае попадания в такое состояние. На том же успешно севшем самолете через день другие пилоты разбились и как показал анализ — они не использовали даже вшитые на уровни ДНК основы пилотирования — тримирование для снятия нагрузки на штурвале. нагрузка плавно(8 минут) нарастала до состояния когда пилот двумя руками обхватив штурвал тянул со всех сил а второй пилот пытался найти в инструкции что делать а делать было известно что — любой нормальный пилот при ощущении нагрузке на штурвале — тримирует самолет тем самым отключая мкас на 5 секунд и так раз в 10-15 секунд щелкая кнопкой тримера можно было спокойно долететь через пол мира а потом на земле уже выяснять каково стабилизатор сам уводился на кабрирование.
        При взлете и посадке мкас не работает так что до этого «глюка» ещё надо было «довести» или долететь.
        Ведь на самом деле подобный «увод» стабилизатора в любую сторону может быть вызван милионом других проблем начиная с глюков бортовой электроники/автопилота/выходу двух датчиков угла атаки из строя так и чисто механическим повреждением самого стабилизатора, его приводов, гидравлики его управления, двигателя электро привода или элементарно контроллера этого двигателя. на этот случай есть четкие давно известные всем инструкции что делать и даже дан шансовый инструмент — тросиковый привод стабилизатора двумя колесами в ногах пилотов. Да усилия там на этих калесах огромные но их можно временно ослабить дав штурвал от себя и провернув колесо а потом оно уже будет крутиться сильно легче — тем легче чем ближе стабилизатор к горизонтали.
        Так что моё мнение — максы не сами падают. как и с сухим — проблемы в консерваториях авиакомпаний и системе подготовки пилотов.

        • richman5
          /#21843950

          Имхо, ошибка программистов в этой ситуации отсутствует по определению. Задачу, от скольких датчиков брать измерения, им ставят другие — конструктора.

        • selivanov_pavel
          /#21844692 / +5

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

  2. unclejocker
    /#21839664

    -del

  3. FromArcanum
    /#21841924

    Где бы посмотреть классификатор ситуаций NASA, в котором есть "high visibility close call" и прочее? Напомнило CFIT для авиации

  4. /#21842070

    Не "выловленные" баги, а не "выявленные" баги — так правильно по русски. Извиняюсь,, конечно.

    • selivanov_pavel
      /#21844708 / +1

      Если на чистом русском, то выявленные проблемы. А на айтишном сленге вполне можно написать выловленные баги .

  5. Rikhmayer
    /#21844994

    NASA и Boeing стали анализировать код на предмет «а не пропустили ли мы еще что-нибудь?»

    Я думал, мы одни такие раздолбаи.

    • Valerij56
      /#21846220 / +3

      Это, как раз, нормальное явление. И в авиации, и в ракетостроении/космонавтике, и даже в мореплавании (и даже во многих других случаях) — при таких авариях и, тем более, катастрофах на невыявленные ранее по тем же схемам проблемы смотрит не только их участник, но и конкуренты и регулирующие органы. Если нет — значит «переоптимизировали», убрали «лишние» койки и врачей, не понимая, что они потребуются при пандемии.