Каково было историческое влияние полета 501 Ariane 5?

Распад ракеты Ariane 5 через 37 секунд после запуска ее первого рейса ( Рейс 501 ) обычно называют одной из самых дорогих программных ошибок в истории ¹ :

Европейскому космическому агентству потребовалось 10 лет и 7 миллиардов долларов для производства Ariane 5, гигантской ракеты, способной выводить на орбиту пару трехтонных спутников при каждом запуске и предназначенной для того, чтобы дать Европе подавляющее превосходство в коммерческом космическом бизнесе.

Все, что потребовалось, чтобы взорвать эту ракету менее чем за минуту до ее первого плавания в июне прошлого года, разбросав огненные обломки по мангровым болотам Французской Гвианы, - это небольшая компьютерная программа, пытающаяся вставить 64-разрядное число в 16-разрядное пространство.

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

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

Я не ищу объяснение самой ошибки, но объясняю историческое влияние ошибки, с точки зрения исследования, которое было вдохновлено или было непосредственно связано с расследованием (ями) отказа. Например, эта статья заключает:

Мы использовали статический анализ для:

• проверить инициализацию переменных,
• предоставить исчерпывающий список потенциальных конфликтов доступа к данным для общих переменных,
• Исчерпывающий список потенциальных ошибок времени выполнения из семантики Ada.

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

Точно так же этот документ ^(pdf) отмечает:

Статический анализ программ, основанный на абстрактной интерпретации, использовался для статического анализа встроенного программного обеспечения ADA программы запуска Ariane 5 и ARD. Статический программный анализатор нацелен на автоматическое обнаружение определенности, потенциальности, невозможности или недоступности ошибок времени выполнения, таких как скалярные и плавающие точки над потоками, ошибки индекса массива, деления на ноль и связанные арифметические исключения, неинициализированные переменные, скачки данных на общие структуры данных и т. д. Анализатор смог автоматически обнаружить ошибку полета Ariane 501. Статический анализ встроенного программного обеспечения, критически важного для безопасности (например, программного обеспечения для авионики), очень перспективен .

Я хотел бы получить подробное объяснение влияния этого отдельного события на подходы и инструменты тестирования программного обеспечения.

_{¹ Цифра в 7 миллиардов долларов, возможно, относится к общей стоимости проекта Ariane 5, сообщает Википедия, что в результате неудачи было потеряно более 370 миллионов долларов. Все еще довольно дорогой провал, но он не приближается к цифре в 7 миллиардов долларов.}

Технически говоря, это был скорее случай " программной гнили ". Программное обеспечение для управления полетом было переработано с более ранней ракеты Ariane 4, разумный шаг, учитывая, насколько дорого стоит разработка программного обеспечения, особенно когда это критически важное программное обеспечение, которое должно быть протестировано и проверено в соответствии с гораздо более строгими стандартами, чем большинство коммерческих программ.

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

Программное обеспечение было разработано так, чтобы определенные параметры никогда не превышали определенных значений (тяга, ускорение, уровень расхода топлива, уровни вибрации и т. Д.). В обычном полете на Ariane 4 это не было проблемой, потому что эти параметры никогда бы не достигли недопустимых значений, если бы что-то уже не было явно неправильным. Ariane 5, однако, намного мощнее, и диапазоны, которые кажутся глупыми на 4-х, могут легко произойти на 5-м.

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

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

Этот конкретный случай был особенно вопиющим, потому что быстрый способ сэкономить деньги обернулся огромной суммой, как с точки зрения денег, так и потери репутации. Если бы программное обеспечение было протестировано в среде, имитирующей Ariane 5, так же надежно, как и при первоначальной разработке для Ariane 4, эта ошибка наверняка обнаружилась бы задолго до того, как программное обеспечение было установлено на оборудовании запуска и введено в команду фактический рейс. Кроме того, если бы разработчик программного обеспечения сознательно бросил какую-то бессмысленную информацию в программное обеспечение, то эта ошибка могла быть обнаружена даже в эпоху Ariane 4, поскольку это высветило бы тот факт, что восстановление после ошибки было неадекватным.

Короче говоря, он не давал новых уроков, но таил в себе опасность не вспоминать старые. Это также продемонстрировало, что среда, в которой работает программная система, так же важна, как и само программное обеспечение. Тот факт, что программное обеспечение достоверно подходит для среды X, не означает, что оно подходит для использования в аналогичной, но отличной среде Y. Наконец, он подчеркнул, насколько важно, чтобы программное обеспечение для критически важных задач было достаточно надежным, чтобы справляться с обстоятельствами, которые не должны иметь место. получилось.

Контраст рейса 501 с Apollo 11 и его компьютерными проблемами. В то время как программное обеспечение LGC страдало от серьезного сбоя во время приземления, оно было разработано, чтобы быть чрезвычайно надежным и могло оставаться в рабочем состоянии, несмотря на сработавшие программные сигналы тревоги, не подвергая астронавтов опасности и все еще способных завершить свою миссию.

Это была проблема повторного использования и управления, а не проблема кодирования. Из моих воспоминаний (я, вероятно, кое-что неправильно) из отчета.

• одна подсистема была разработана для Ariane IV. Траектории Ariane IV не могли привести к переполнению, и тогда было преднамеренно решено, что, если это произошло, это была аппаратная проблема, и выключение подсистемы и переход на запасную часть были правильными.

• для Ariane V было решено повторно использовать эту подсистему и не пересматривать предположения и код, а полагаться на тестирование.

• далее было решено отказаться от полного тестирования.

Различные параметры полета Ariane V обусловили переполнение. Завершите основной. Выключи запасной. Саморазрушение.

Дополнительные вещи, которые я помню:

• Подсистема во время переполнения больше не была полезна. Можно утверждать, что его отказ не должен был вызвать самоуничтожение. (С другой стороны, дополнительная сложность сама по себе может стать источником проблем).

• были отладочные данные, отправленные на шину, когда это не должно было быть. Я не помню конкретного.

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