Яким був історичний вплив польоту 501 Ariane 5?

Дезінтеграція ракети "Аріана 5" через 37 секунд після запуску в дівоче плавання ( Flight 501 ) прийнято називати однією з найдорожчих програмних помилок в історії ¹ :

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

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

Одна помилка, одна аварія. З усіх необережних рядків коду, записаних у літописі інформатики, цей може бути найбільш руйнівним. З інтерв'ю з експертами з ракетної зброї та аналізом, підготовленим для космічного агентства, з'являється чіткий шлях від арифметичної помилки до повного знищення.

Які основні зміни призвели до відмови Flight 501 та подальших розслідувань для дослідження критично важливих систем безпеки та тестування програмного забезпечення?

Я не шукаю пояснення самої помилки, а для пояснення історичного впливу помилки, з точки зору досліджень, які були натхнені або були безпосередньо пов’язані з дослідженнями провалу. Наприклад, у цьому документі робиться висновок:

Ми використовували статичний аналіз для:

• перевірити ініціалізацію змінних,
• надати вичерпний список потенційних конфліктів доступу до даних для загальних змінних,
• вичерпно перерахуйте потенційні помилки часу виконання з семантики Ада.

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

Аналогічно цей документ ^(pdf) зазначає:

Статичний аналіз програм на основі абстрактних інтерпретацій був використаний для статичного аналізу вбудованого програмного забезпечення ADA пускової установки Ariane 5 та ARD. Статичний програмний аналізатор спрямований на автоматичне виявлення визначеності, потенційності, неможливості або недоступності помилок під час виконання, таких як скалярні та «точки відхилення» над fl ows, помилки індексу масиву, розділення на нуль та пов'язані з ними арифметичні винятки, неініціалізовані змінні, перегони даних на спільні структури даних тощо. Аналізатор зміг автоматично виявити помилку Ariane 501 fl. Статичний аналіз вбудованого критичного для безпеки програмного забезпечення (наприклад, авіонічного програмного забезпечення) є дуже перспективним .

Мені б хотілося детально пояснити вплив цієї події на підходи та інструменти тестування програмного забезпечення.

_{¹ Ця цифра в 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 зазнало серйозних збоїв під час посадки, воно було розроблене надзвичайно надійно і було здатне залишатися в робочому стані, незважаючи на тривогу програмного забезпечення, не створюючи небезпеки космонавтам і не маючи можливості завершити свою місію.

Це здебільшого була проблема повторного використання та управління, а не кодування. З моїх спогадів (я, мабуть, неправильно розумію деякі речі) звіту.

• одна підсистема була розроблена для Аріана IV. Траєкторії Ariane IV не могли призвести до переповнення, і тоді було навмисно вирішено, що якщо це відбудеться, це проблема апаратури, і вимкнення підсистеми та перехід на запасні - це правильна річ.

• для Ariane V було вирішено повторно використовувати цю підсистему і не переглядати припущення та код, а покластися на тестування.

• далі було вирішено кинути повне тестування.

Різні параметри польоту Ariane V спричинили перелив. Вимкніть первинне. Вимкніть запасні. Автореструктура.

Додаткові речі, які я пам’ятаю:

• підсистема в момент переповнення не була більш корисною. Можна стверджувати, що його збій не повинен був спровокувати автоструктурування. (З іншого боку, додаткова складність сама по собі може бути джерелом проблем).

• дані про налагодження надсилалися в шину, коли вона не повинна. Я не пам’ятаю конкретного.

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