[Космонавтика, Научно-популярное, Тестирование IT-систем] Тестировать больше и лучше: Закончился разбор аварийного полета Boeing Starliner
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
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.
===========
Источник:
habr.com
===========
Похожие новости:
- [Будущее здесь, Космонавтика, Экология] НАСА обновило свою политику мерами против загрязнения Луны и Марса
- [Высокая производительность, Производство и разработка электроники, Разработка под Linux, Сетевые технологии, Тестирование IT-систем] Генератор трафика Cisco TRex: запускаем нагрузочное тестирование сетевых устройств
- [Космонавтика, Разработка систем связи, Сотовая связь] Компания «Спутниковая система «Гонец» разработала кейс экстренной связи через спутники «Гонец-М»
- [Исследования и прогнозы в IT, Научно-популярное, Здоровье] COVID-19: Модель параметрического предсказания эпидемии
- [Космонавтика] Аварийный запуск. 51-й в 2020 году. 19-й от Китая. Потеряны новая ракета KZ-11 и два спутника
- [Data Mining, Анализ и проектирование систем, Научно-популярное] Байесовские сети при помощи Питона — что и зачем?
- [Космонавтика] Успешный запуск. 50-й в 2020 году! 18-й от Китая. Тяжелый коммерческий спутник связи на GEO
- [Инженерные системы, Научно-популярное, Физика] Создана СТЕЛС-технология, полностью скрывающая металлические мачты и антенны
- [Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений] Как найти границы на клиенте и сервере
- [Занимательные задачки, Космонавтика, Разработка игр, Учебный процесс в IT] Игры от Илона Маска для детей 8-14 лет (играем всем Хабром в комментах)
Теги для поиска: #_kosmonavtika (Космонавтика), #_nauchnopopuljarnoe (Научно-популярное), #_testirovanie_itsistem (Тестирование IT-систем), #_boeing_starliner, #_pilotiruemaja_kosmonavtika (пилотируемая космонавтика), #_ispytanija (испытания), #_kosmicheskie_proisshestvija (космические происшествия), #_testirovanie_po (тестирование ПО), #_quality_assurance, #_decision_coverage, #_kosmonavtika (
Космонавтика
), #_nauchnopopuljarnoe (
Научно-популярное
), #_testirovanie_itsistem (
Тестирование IT-систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:40
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
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. =========== Источник: habr.com =========== Похожие новости:
Космонавтика ), #_nauchnopopuljarnoe ( Научно-популярное ), #_testirovanie_itsistem ( Тестирование IT-систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 12:40
Часовой пояс: UTC + 5