30 жовтня 1997 р. із космодрому Куру (Kourou) у французької Гвіані успішно зроблений пробний запуск ракети-носія Ariane 5. На 37-й секунді після старту: ракета Ariane 5 відхилилася від розрахункової траєкторії, початку руйнуватися в повітрі і вибухнула.
Аварія сталася через однією-єдину помилку в програмному забезпеченні, наслідки ж виявилися дуже серйозними. Це була, мабуть, найдорожча в історії ПЗ помилка: адже на реалізацію проекту Ariane 5 витрачено 8 млрд. дол.., а вартість супутників серії, що знаходилися на борту, Cluster складала 500 млн. дол..
Катастрофа Ariane 5 порівняна хіба що з трагічним вибухом американського корабля Challenger (28 січня 1986 р. ).Як показали результати вивчення телеметрії, різка зміна траєкторії і зміна кута атаки були викликані відхиленнями сопів, що у свою чергу ініціювали командами бортового комп'ютера. При опрацюванні даних в основному комп'ютері виник програмний виняток (переривання по позаштатній ситуації). Переключення на резервний комп'ютер не відбулося, оскільки він перервав свою роботу під час попереднього циклу знімання даних з тієї ж самої причини, що й основний. Джерелом виникнення винятку стала операція перетворенню даних із 64-розрядного числа з плаваючою комою в 16-розрядне знакове ціле. Значення виявилося більшим, ніж дозволяла розрядна сітка. У результаті був збуджений виняток Operand Error (помилка операнда). На жаль, у програмному коді, написаному на мові Ada, опрацювання для даного винятку передбачено не було.
Причина катастрофи - помилка в програмі. Але що ж викликало самому помилку? Некомпетентність фахівців? Ні, усі говорить за те, що процес розробки організований і спланований ретельно. Може бути справа в некоректному управлінні процесом розробки? Теж немає. Звичайно, при веріфікації були допущені прорахунки, але усе ж причина виявилася чисто технічною. Так у чому ж справа? У мові програмування?
У мові Ada за не дуже вдалий механізм опрацювання винятків, але в даному випадку він не причому. Далеко не всі перетворення типів виявилися під захистом оброблювачів винятків. Тестування на предмет виявлення помилки операндів привело до введення захисту для чотирьох із семи можливих змінних, що відносяться до критичного фрагмента коду на мові Ada. На жаль, помилка проявилася саме в одній із трьох неконтрольованих змінних. Як програміст це упустив?
Справа в тому, що, із його точки зору, подібної ситуації бути просто не могло. Але міркування розроблювача були правильними для траєкторії Ariane 4, однак траєкторія Ariane 5 мала зовсім інші параметри. Проблема виникнула на стику надійності й ефективності. Дотримання всіх правил контролю приводило до неминучого росту накладних витрат, а тому програмісти шукали компроміси.
Конструкція вузла IRS для Ariane 5 майже в точності збігалася з тієї, що використовувалася в Ariane 4; це стосувалося і програмного забезпечення. Після збою в інерційній системі IRS дані телеметрії продовжували надходити на бортовий комп'ютер, що інтерпретував їх як реальні параметри польоту. При спробі програмним способом обробити помилкові дані значення горизонтальної швидкості перевищило передбачений діапазон представлення, у результаті чого і виник виняток. У випадку Ariane 4 такої ситуації виникнути не могло, але носій Ariane 5 мав цілком інші швидкісні характеристики.
Програмне забезпечення для Ariane 4 було написано на діалекті Ada 83, і 23 успішних запуску підтвердили його надійність. Однак адаптація ПЗ для проекту Ariane 5 пройшла без належної ревізії вже створених програмних будівельних блоків. На жаль, зроблені в них допущення суперечили специфікаціям нової програми польоту.
Весь трагізм ситуації перебував у тому, що обчислення, що забезпечують вирівнювання інерційної платформи, у котрих і виник виняток, під час польоту взагалі були не потрібні! Вони повинні були відключитися за 9 секунд до старту. Вимогу продовжувати обчислення для компенсації відходу інерційної платформи після старту було обов'язковим для Ariane 4, але не для Ariane 5! У підсумку значення горизонтальної швидкості виявилося вище, чим припускали розроблювачі. Потому-то і виник цілком непередбачений виняток.
Як зазначають фахівці, першопричина була в некоректному вторинному використанні вже налагоджених компонентів (модуль контролю за горизонтальним зсувом був запозичений із ПЗ для Ariane 4, розробленого десять років тому). Ситуацію міг спасти механізм інваріантів (assertion), що дозволяє не просто описувати пред- і постумови операцій. Цей механізм задає іншу форму відношень між елементами програмної системи - форму контрактів, зобов'язань, що закладаються ще на етапі проектування. Подібний підхід Мейер називає проектуванням за контрактом (Design by Contract), що припускає забезпечення контролю за дотриманням специфікацій. Якби при розробці ПЗ для Ariane 5 використовувалися хоча б ці напівформальні прийоми, якби надійності приділялося більше уваги, аварії б не відбулося.
Уроки аварії Ariane 5
17 років тому Чарльз Хоар (Charles Hoare), відомий англійський вчений з Оксфордского університету, на церемонії вручення йому престижній премії Алана Тьюринга висловив тривогу з приводу індиферентного відношення людей до проблем надійності. Об'єктом його критики був узятий на озброєння Міністерством оборони США мова Ada. Справедливості заради треба сказати, що з 1980 р. дана мова перетерпіла певні зміни, що знайшли відбиток у стандарті Ada 95. Але справа не в конкретній мові, а у відношенні людей до можливих наслідків використання ненадійного ПО.
"Я звертаюся до вас, представникам програмістської громадськості США,- сказав тоді Хоар, - а також до громадян, причетним до добробуту і безпеки вашої країни і всього людства: не дозволяйте використовувати цю мову в його теперішньому стані в додатках, надійність яких критично важлива (таких, як атомні електростанції, крилаті ракети, системи раннього оповіщення і протиракетної оборони). Наступна ракета, що зіб'ється в шляху в результаті огріху в мові програмування, може виявитися не дослідним космічним зондом, що летить у необразливу подорож до Венері; це може бути носій із ядерною боєголовкою, що вибухне над одним із наших міст. Ненадійна мова програмування, що породжує ненадійні програми, представляє для навколишнього середовища і нашого суспільства незрівнянно більший ризик, чим небезпечні автомобілі, токсичні пестициди або атомні станції".
На жаль, історія нас так нічому і не учить. Жодний із загальновідомих мовних інструментів - Java, COBRA (IDL), Active, Ada 95 - не забезпечує того рівня надійності, який усі активніше вимагає реальне життя (у даному випадку мова навіть не йде про замовлення військово-промислового комплексу).
Уроки аварії Ariane 5 не пройшли даром. Вона стимулювала інтерес промислових кіл до передових європейських досліджень в галузі створення, верифікації і тестування систем підвищеної надійності (safety-critical systems). Схоже, наступає ера активного застосування формальних методів (formal methods), що забезпечують контроль за дотриманням найвищого ступеня цілісності систем. Яскравими прикладами удалого впровадження цих методів можуть служити проекти створення Обчислювального вузла для трансп’ютера Inmos T800, а також система опрацювання транзакцій IBM CICS. Все більша увага приділяється проблемам адаптивних архітектур, що обпираються на винятки. Вони найбільше ефективні для управління ступенем реконфігурації і деградації складних убудованих систем реального часу, що пред'являють підвищені вимоги до надійності. Неминучий перегляд інструментарію і методів розробки торкає основи індустрії програмного забезпечення, включаючи самі мови програмування, що виконують системи мов, базові бібліотеки модулів і класів, а також весь операційний контекст програмних систем і компонентів.