Тестировать больше и лучше: Закончился разбор аварийного полета Boeing Starliner
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.
