Старлайнер преподнес компании Боинг тяжелый урок о том как не следует тестировать программное обеспечение

M. Rozum

Статті

От себя: я понимаю, что баги Старлайнера это уже “баян”, но материал вышел только сегодня и в нем есть пара интересных вещей, а также одно утверждение от которого у меня на голове волосы (хорошо, что их почти не осталось) встали дыбом.

7251

От себя: я понимаю, что баги Старлайнера это уже “баян”, но материал вышел только сегодня и в нем есть пара интересных вещей, а также одно утверждение от которого у меня на голове волосы (хорошо, что их почти не осталось) встали дыбом.


Старлайнер поднят на вершине ракеты ULA Atlas V во время подготовки к тестовому орбитальному полету
Фото: Кори Хастон/NASA

Проект компании Боинг  CST-100 Старлайнер, многократно используемая капсула для доставки астронавтов на низкую околоземную орбиту (НОО), возможно и выглядит как прошлые поколения космических кораблей, но внешность бывает обманчивой.

“Мы более не создаем аппараты в которые встраивается чуточка программного кода”, говорит Патриша Сэндерс, возглавляющая давно существующую консультативную группу по аэрокосмической безопасности NASA (NASA Aerospace Safety Advisory Panel  – ASAP). “Напротив, мы создаем ПО, вокруг которого уже создается аппаратное обеспечение, в то же время мы еще не достигли того уровня на котором мы могли бы стандартизировано применять строгие наборы инженерных подходов разработки ПО”.

  • требуется пересмотреть 1 миллион строк кода 
  • NASA запускает процедуру аудита безопасности (прим.: имеется в виду контроль качества – “safety”, а не “безопасность от врагов”, которая была бы “security” ) компании Боинг

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

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

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

Если бы эта неисправность не была бы устранена, то “это привело бы к ошибочному включению маневрового двигателя и неконтролируемому движению во время отделения служебного модуля при сходе с орбиты, что потенциально могло бы привести к катастрофическим последствиям.”, говорит член ASAP Пол Хилл, бывший директор управления полетами NASA.

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

“Процесс был нарушен во многих областях”, говорит начальник по космическим полетам NASA Даглас Ловерро, “и мы не знаем сколько ошибок в программном обеспечении существует на данный момент, не знаем две ли ошибки или их сотни”, так же Ловерро отметил, что вина не возлагается исключительно на Боинг – “надзор NASA был недостаточен, это очевидно и это хороший урок для нас”.

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

“Как государству нам нужны, и у нас есть обязательство в этом, несколько поставщиков способных доставить нас на низкую околоземную орбиту”, сообщил администратор NASA Джим Брайденстайн на встрече с репортерами 7го февраля. “Это то чем является программа коммерческих полетов и мы очень усердно работаем для того чтобы понять с чем связаны неисправности Старлайнера, для того чтобы их устранить и двигаться дальше”.

NASA и Боинг соглашаются в том, что еще рано говорить, потребуется ли второй тестовый беспилотный полет Старлайнера перед отправкой астронавтов – миссии, запланированной на этот год, Боинг также не комментирует то, сколько времени потребуется для проверки всего ПО Старлайнера, а это порядка 1 миллиона строк кода.

Во время тестового полета мы успешно испытали 66% всех  сценариев (прим.: возможно имеются в виду “скрипты”)  которые у нас были, но мы не готовы признать, что проблем нет”, говорит Джон Малхолланд, программный менеджер Боинг Старлайнер, “наша команда, вместе с NASA, полностью пересмотрит правильность реализации функционала ПО”.

В настоящий момент, NASA продолжает консультировать SpaceX чтобы та продолжила работу над своим проектом, особенно принимая во внимание сокращение персонала связанного с МКС (прим.: тут мог ошибиться, “ISS staffing ramping down”)  вызванным тем, что контракт для полетов астронавтов на борту Российских капсул Союз близится к концу. В настоящий момент последнее оплаченное США место зарезервировано для ветерана NASA, астронавта Криса Кэсиди, в миссии запланированной к запуску в апреле.

Источник:

https://aviationweek.com/defense-space/starliner-gives-boeing-hard-lesson-how-not-verify-software

48 коментарів

Розгорнути всі

Будь ласка, у свій профіль, щоб коментувати пости, робити закладки та оцінювати інших користувачів. Це займає всього два кліки.

Лют 18, 2020 08:36

Программисты из Индии: “…таймер был установлен на 11 часов вперед по отношению к фактическому времени миссии”

Лют 18, 2020 09:52

Типа того. Хотя с Индией разница 10,5 часов.

Лют 21, 2020 14:31

Они округлили чтобы не палиться

Лют 18, 2020 10:55

Программисты из ИндииСкорее, сисадмины -часовой пояс устанавливается на уровне операционки.

Лют 18, 2020 17:23

Возможно, но не факт, да и при хорошем менеджменте эта проблема была бы нивелирована. От Боинга пока “который год в подполе происходит подземный стук” из которого можно сделать, очень теоретизируя при этом конечно, несколько выводов:
– Тут могу ошибаться, но похоже, что менеджмент совершенно потерял контроль над тем, что чудят вендоры.
– Сама передача таких проекта вендорам (если это так) вызывает вопросы, поскольку в вакансиях Боинга четко указано требование гражданства и способность получить допуск по безопасности. И при этом пускать вендоров в такие проекты…. выглядит странным
– Так же похоже на то, что космическое подразделение Боинга это какой-то сферический конь в вакууме существующий в отрыве от всего остального мира, потому, что через 40 лет после создания F-117 (хотя это и Локхид, но все же) говорить ту фразу которую сказала мисс Сэндэрс из NASA в начале статьи – тут никаких волос на голове не хватит и всю ладонь фейспалмом можно отбить

Лют 19, 2020 11:28

Сегодня прочитал, что в баках 737МАХ находят посторонние предметы – инструменты, тряпки и т.п. Боинг под управлением нынешних “эффективных менеджеров” тупо скатывается в какое-то днище.

Лют 18, 2020 11:35

Выходит и правда американский корабль мог развалиться на орбите

Лют 18, 2020 12:40

А чей-то сразу:”развалиться”? Так, поцарапаться малость.

Лют 18, 2020 12:45

А, ну тогда ничего страшно. Просто будет такая Колумбия 2, да и ладно

Лют 18, 2020 19:28

Просьба автору вычитывать текст на пунктуацию: выделять причастные и деепричастные обороты ЗАПЯТЫМИ, и ставить их перед словами типа “который” и т.д.!!! Это в инглише запятые в этих местах обычно не ставятся, а в “общепонятном” ставятся! Спасибо!
А по сабжу статьи – тем хуже для Боинга! А то зажрались на распиле госбюджета, пусть хоть поработают, что ли…

Лют 18, 2020 21:50

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

Лют 18, 2020 21:56

“На обиженных воду возят” (С) А переводить надо “больше, но чаще” (С) 🙂

Лют 18, 2020 23:09

Мне кажется, что технический английский сегодня должен знать каждый.
Вопрос перевода на общепонятный – это, с моей точки зрения, высший пилотаж, не каждый может произвести хороший литературно-технический перевод.
Но… мне также кажется, что ну оооочень уважаемая тусовка на альфацентавре имеет IQ выше 150-ти, и не нуждается в таких переводах, не так ли? 🙂

Лют 18, 2020 21:57

Фантастика.В который раз убеждаюсь,что обилие модных штук в лексиконе манагеров начисто выбивает мозги инженерам.Есть вопросы.Первое – как можно на скриптах писать такое ПО.Наняли сайтостроителей?Скрипт прост,дешев в разработке,но непредсказуем -он компилируется в момент выполнения.Его легко править,но сложно тестировать.Кстати,любой скрипт – это до исполнения текст,что открывает дополнительные возможности злоумышленникам. Второе – ошибка с таймером – даже не верится.Привязать относительный отсчет времени к астрономическому? Скорее всего,использован какой-то стандартный объект или функция языка,не до конца понятный самим разработчикам.Либо это такая синхронизация нескольких разнородных подсистем разных разработчиков(дорого и ненадежно).Третье,раз уж такие богатые,код должен содержать средства для тестирования.И неважно,сколько строк кода.В конце-концов сегодня тестирование ПО выделилось в отдельную специальность.И еще,я уверен,что сам алгоритм работы аппарата намного проще,чем его реализация.Сегодня постоянно используется комп+ос+например питон для сработки какой-либо защелки или зажигания лампочки.Хотя в кодах это два десятка байт.Но тутхоть понятно-так дешево,а космический корабль…

Лют 18, 2020 23:38

Скрипты это не обязательно джаваскрипт или шелл, ПО для железа давно не пишется на ассемблере (хотя после слов мисс Сэндерс я ничему не удивлюсь). Скрипт это, в общем, небольшая программа написанная, зачастую, но не обязательно, на интерпретируемом языке и вызываемая по наступлению определенного события, именно отсюда и сноска с переводом как “сценарий”, поскольку не понятно о чем именно человек говорил.
PS: насчет второго и третьего это уже теоретизирование – ни Вы ни я кода Старлайнера в глаза не видели, не знаете на чем ведется разработка и как осуществляется тестирование. Ошибка могла произойти где угодно и от чего угодно, проблема в том, что система контроля качества ее пропустила.

Лют 18, 2020 23:42

Скрипты это не обязательно джаваскрипт.Та же LUA, например.

Лют 18, 2020 23:44

Привязать относительный отсчет времени к астрономическому? “Астрономическое время” – это какое?

Лют 19, 2020 18:13

“… мы создаем ПО, вокруг которого уже создается аппаратное обеспечение …” Оригинальный подход. А может ну его – это аппаратное обеспечение? Мешает только!

Лют 19, 2020 18:20

Под правильный софт от “Боинга” были приобретены неправильные китайские часы.

Лют 20, 2020 17:14

Ваше возмущение непонятно – тренду переноса функционала с железа на ПО уже лет 40 как, если не больше. Вызван тем, что устранять неисправности и модифицировать проще ПО, чем аппаратуру и странно если сегодня кто-то с этим дискутировать будет. Взять те же проблемы Старлайнера – если бы все делало “железо”, то после описанных проблем программа бы ущла в ступор надолго, сейчас же они за пару месяцев проведут аудит кода, исправят, уберут проблемы контроля качества и снова встанут в очередь на запуск.

Лют 20, 2020 09:24

Вот уж правда: Делать просто – сложно.
Никто не знает сколько строк кодо у Дракона?
Мое сугубо личное мнение, миллион строк кода слишком много. А чем сложнее что-то тем больше вероятность ошибки.

Лют 20, 2020 10:01

Вот уж правда: Делать просто — сложно.От сложного к простому.
Никто не знает сколько строк кодо у Дракона?Не уверен, что Спейсы сами знают. Просто считать строки – бесполезное занятие. А вообще, 1 миллион строк можно запихнуть в 1 строку. Миллион строк нужно для понимания человеком кода, а не машиной.
Мое сугубо личное мнение, миллион строк кода слишком много. А чем сложнее что-то тем больше вероятность ошибки.Элементарная программа – до 10 тыс. строк, средняя – до 100 тыс., сложная – от 100 тыс. и это норма. Меньше сделать – ну, это просто круто. Какой-то поганый интернет магазин – это уже приложение среднего уровня, минимум. Дракон – очень сложная система, кода там хватает. Да, чем меньше, тем лучше, но не получится. Если ранее делали железо и немного софта, то сейчас железо делается под софт. Это удобней и практичней, ибо железо научились делать… а вот софт – еще сложный процесс. Разработка идет уже более 5 лет. Я бы не рассчитывал на то, что у Дракона кода менее, чем 1 миллион строк.

Лют 20, 2020 17:16

“миллион строк” в данном случае (по моему личному мнению) просто неудачная попытка Боинга оправдаться – “смотрите как у нас все сложно, тут кто угодно способен ошибиться”. Поэтому придавать значение этой цифре не стоит, мы не знаем как они этот миллион насчитали.

Лют 21, 2020 14:30

как они этот миллион насчитали.
Что-то мне подсказывает, что вместе со сторонними библиотеками

Бер 03, 2020 23:36

Все ветки в git-е посчитали наверное, так у нас наверно миллиард строк уже)))

Лют 23, 2020 15:45

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