Париж, 19 липня 1996

ARIANE 5

Аварія польоту 501

Звіт комісії з розслідування

Голова комісії :

Проф. J. L. LIONS

[спочатку опубліковано в http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html]

[перекладено із https://www-users.cse.umn.edu/~arnold/disasters/ariane5rep.html]

Передмова

4 червня 1996 року перший політ ракети-носія Ariane 5 завершився аварією. Всього приблизно через 40 секунд після початку польотної програми, на висоті близько 3700 метрів, носій зійшов з траєкторії, розпався та вибухнув. Інженери з команд проєкту Ariane 5 від CNES та промислових підприємств негайно розпочали розслідування аварії. У наступні дні Генеральний директор ESA та Голова CNES створили незалежну Розслідувальну комісію та призначили до її складу таких членів:

  • Проф. Жак-Луї Ліон (голова) Академія наук (Франція)
  • Д-р Леннарт Льобек (заступник голови) Шведська космічна корпорація (Швеція)
  • Пан Жан-Люк Фокемберґ Головне управління з озброєнь (Франція)
  • Пан Жиль Кан Національний інститут досліджень в галузі інформатики та автоматики (INRIA) (Франція)
  • Проф. д-р інж. Вольфганг Куббат Технічний університет Дармштадта (Німеччина)
  • Д-р інж. Стефан Леведаг Daimler Benz Aerospace (Німеччина)
  • Д-р інж. Леонардо Мацціні Alenia Spazio (Італія)
  • Пан Дідьє Мерль Thomson CSF (Франція)
  • Д-р Колін О’Галлоран Агентство з оцінки та досліджень у сфері оборони (DERA) (Велика Британія)

У дорученні, наданому комісії, зазначалося, що їй необхідно

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

Комісія розпочала свою роботу 13 червня 1996 року. Їй надавала допомогу Технічна консультативна група у складі:

  • Д-р Мауро Балдуччіні (BPD)
  • Пан Іван Шокер (Matra Marconi Space)
  • Пан Ремі Ерго (CNES)
  • Пан Бернар Юмбер (Aérospatiale)
  • Пан Ерік Лефор (ESA)

Відповідно до свого мандату, Комісія зосередила розслідування на причинах аварії, системах, які могли бути відповідальними, можливих відмовах подібного характеру в аналогічних системах та подіях, що могли мати зв’язок з інцидентом. Відповідно, рекомендації Комісії обмежуються лише розглянутими питаннями. Звіт містить аналіз аварії, висновки Комісії та її рекомендації щодо коригувальних заходів, більшість з яких слід здійснити до наступного польоту Ariane 5. Додатково існує звіт з обмеженим розповсюдженням, у якому висновки Комісії задокументовані з більшою технічною деталізацією. Хоча Комісія використовувала телеметричні дані, записані під час польоту, вона не проводила їхньої повної оцінки. Так само не було виконано всебічного огляду всього носія та його систем.

Цей звіт є результатом колективної роботи Комісії за участю членів Технічної консультативної групи.

Ми всі доклали значних зусиль, щоб надати максимально точне пояснення причин аварії та зробити внесок у вдосконалення програмного забезпечення Ariane 5. Це вдосконалення є необхідним для забезпечення успіху програми.

Висновки Комісії ґрунтуються на всебічних і відкритих доповідях команд проєкту Ariane 5, а також на документації, яка засвідчила високу якість програми Ariane 5 у частині інженерних робіт загалом, а також повноту та простежуваність документів.

Голова комісії

1. АВАРІЯ

1.1 Загальний опис

На підставі наданої документації та інформації, представленоï Комісії, було встановлено таке:

Погодні умови на стартовому майданчику в Куру вранці 4 червня 1996 року були прийнятними для запуску цього дня і не створювали перешкод для транспортування носія на стартовий стіл. Зокрема, ризику ураження блискавкою не було, оскільки напруженість електричного поля, виміряна на місці запуску, була незначною. Єдина невизначеність стосувалася виконання критеріїв видимості.

Зворотний відлік, що включав також заправку центрального ступеня, проходив без ускладнень до моменту H0-7 хвилин, коли запуск було призупинено через невідповідність критеріям видимості на початку вікна запуску (08:35 за місцевим часом). Умови видимості покращилися, як і прогнозувалося, і запуск було здійснено в H0 = 09:33:59 за місцевим часом (= 12:33:59 UT). Запалювання двигуна Vulcain та двох твердопаливних прискорювачів відбулося штатно, як і відрив від стартового столу. Політ ракети проходив у нормальному режимі до приблизно H0 + 37 секунд. Невдовзі після цього вона різко відхилилася від траєкторії, зруйнувалася та вибухнула. Попередній аналіз даних польоту показав:

  • штатна робота носія до H0 + 36 секунд;
  • відмова резервної інерціальної референсної системи, за якою відразу послідувала відмова активної інерціальної референсної системи;
  • відхилення сопел двох твердопаливних прискорювачів у крайнє положення і, трохи пізніше, сопла двигуна Vulcain, що спричинило різкий відхід носія з траєкторії;
  • правильне спрацювання системи самоліквідації носія, викликане руйнуванням зв’язків між твердопаливними прискорювачами та центральним ступенем.

Таким чином, причину аварії досить швидко було звужено до системи керування польотом і, зокрема, до інерціальних референсних систем, які, очевидно, майже одночасно припинили роботу приблизно на H0 + 36,7 секунди.

1.2 НАЯВНА ІНФОРМАЦІЯ

Наявна інформація щодо запуску включає:

  • телеметричні дані, отримані на Землі до H0 + 42 секунди
  • дані про траєкторію з радарних станцій
  • оптичні спостереження (інфрачервона камера, кінозйомка) - огляд вилучених фрагментів.

Усі телеметричні дані, отримані в Куру, були передані до CNES у Тулузі, де їх було перетворено у графіки залежності параметрів від часу. CNES надало копію цих даних компанії Aérospatiale, яка провела аналіз, зосередившись головним чином на інформації щодо електричної системи.

1.3 ВИЛУЧЕННЯ МАТЕРІАЛІВ

Самоліквідація носія відбулася неподалік від стартового майданчика, на висоті приблизно 4000 м. Унаслідок цього всі уламки носія впали на землю, розсипавшись на території площею близько 12 км² на схід від стартового майданчика. Вилучення матеріалів було ускладнене, оскільки ця територія майже повністю складається з мангрових боліт та савани.

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

1.4 ВИЯВЛЕНІ НЕПОВ’ЯЗАНІ АНОМАЛІЇ

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

Однією з аномалій, на яку Комісія звернула особливу увагу, був поступовий розвиток, починаючи з H0 + 22 секунди, коливань у гідравлічному тиску приводів сопла головного двигуна. Частота цих коливань становила приблизно 10 Гц.

Існують попередні пояснення причин цих коливань, які наразі перебувають на стадії дослідження.

Після розгляду Комісія дійшла висновку, що ця аномалія, хоч і є суттєвою, не має відношення до аварії Ariane 501.

2. Аналіз аварії

2.1 ЛАНКА ТЕХНІЧНИХ ПОДІЙ

У загальних рисах Система керування польотом Ariane 5 має стандартну конструкцію. Орієнтація ракети-носія та її рух у просторі вимірюються Інерціальною референсною системою (SRI). Вона має власний внутрішній комп’ютер, у якому кути та швидкості обчислюються на основі інформації з інерціальної платформи типу «strap-down», оснащеної лазерними гіроскопами та акселерометрами. Дані з SRI передаються через шину даних до бортового комп’ютера (OBC), який виконує програму польоту та керує соплами твердопаливних прискорювачів і кріогенного двигуна Vulcain через сервоклапани та гідравлічні приводи.

Для підвищення надійності передбачена значна надлишковість на рівні обладнання. Дві SRI працюють паралельно, маючи ідентичне апаратне та програмне забезпечення. Одна SRI активна, а інша перебуває у «гарячому» резерві, і якщо OBC виявляє відмову активної SRI, він негайно перемикається на іншу за умови, що цей блок функціонує належним чином. Аналогічно, є два OBC, а також низка інших блоків Системи керування польотом дубльована.

Конструкція SRI для Ariane 5 практично така сама, як у SRI, що використовується на Ariane 4, зокрема щодо програмного забезпечення.

На основі наданої Комісії широкої документації та даних щодо аварії Ariane 501 встановлено наступний ланцюг подій, їх взаємозв’язки та причини, починаючи з руйнування ракети-носія і простежуючи їх у зворотному напрямку до першопричини.

  • Руйнування ракети-носія почалося приблизно на H0 + 39 секунді через високі аеродинамічні навантаження, викликані кутом атаки понад 20 градусів. Це призвело до відокремлення прискорювачів від основного ступеня й, у свою чергу, запустило систему самоліквідації ракети.
  • Цей кут атаки був спричинений повними відхиленнями сопел твердопаливних прискорювачів і головного двигуна Vulcain.
  • Такі відхилення сопел були задані програмним забезпеченням бортового комп’ютера (OBC) на основі даних, переданих активною інерціальною референсною системою (SRI 2). Частина цих даних на той момент не містила коректних польотних параметрів, а відображала діагностичний шаблон бітів комп’ютера SRI 2, який був інтерпретований як польотні дані.
  • Причиною того, що активна SRI 2 не передавала правильних даних про орієнтацію, було те, що пристрій оголосив про збій через програмне виключення.
  • OBC не зміг перемкнутися на резервну SRI 1, оскільки та вже вийшла з ладу під час попереднього циклу даних (тривалістю 72 мілісекунди) з тієї ж причини, що й SRI 2.
  • Внутрішне програме виключення у SRI був викликано під час виконання операції перетворення числа з формату 64-бітного з плаваючою комою у 16-бітне ціле зі знаком. Число мало значення, більше за те, яке можна було представити у 16-бітному цілому зі знаком. Це призвело до помилки «Operand Error». Інструкції перетворення даних (у коді Ada) не мали захисту від виникнення такої помилки, хоча інші аналогічні перетворення в тому ж місці коду були захищені.
  • Помилка виникла в тій частині програмного забезпечення, яка виконує лише вирівнювання інерціальної платформи типу «strap-down». Цей програмний модуль обчислює значущі результати тільки до моменту старту. Як тільки ракета злітає, ця функція вже не має жодного практичного призначення.
  • Функція вирівнювання залишається активною протягом 50 секунд після запуску «Режиму польоту» SRI, що відбувається на H0 - 3 секунди для Ariane 5. Отже, після відриву ракети від землі ця функція продовжує працювати ще близько 40 секунд польоту. Така часовa послідовність була заснована на вимогах Ariane 4 і не була необхідною для Ariane 5.
  • «Operand Error» виникла через неочікувано високе значення внутрішнього результату функції вирівнювання під назвою BH (Horizontal Bias — горизонтальне зміщення), пов’язане з горизонтальною швидкістю, яку визначала платформа. Це значення використовується як індикатор точності вирівнювання з часом.
  • Значення BH було значно вищим за очікуване, оскільки початкова частина траєкторії Ariane 5 відрізняється від Ariane 4 і призводить до набагато більших значень горизонтальної швидкості.

Внутрішні події в SRI, що призвели до збою, були відтворені шляхом моделювання. Крім того, обидві системи SRI були відновлені під час розслідування Комісії, і контекст збою був точно визначений завдяки зчитуванню пам’яті. Додатково Комісія вивчила програмний код, який виявився узгодженим із встановленим сценарієм збою. Результати цих досліджень задокументовані в Технічному звіті.

Таким чином, поза всяким сумнівом встановлено, що наведений вище ланцюг подій відображає технічні причини аварії Ariane 501.

2.2 КОМЕНТАРІ ЩОДО СЦЕНАРІЮ ЗБОЮ

У сценарії збою основними технічними причинами стали помилка операнда під час перетворення змінної горизонтального зсуву BH та відсутність захисту цього перетворення, що призвело до зупинки роботи комп’ютера SRI.

Комісії було повідомлено, що не всі перетворення були захищені, оскільки для комп’ютера SRI було встановлено цільове обмеження максимальної завантаженості у 80%. Для визначення вразливості незахищеного коду було проведено аналіз усіх операцій, які могли призвести до виключення, зокрема помилки операнда. Зокрема, було проаналізовано перетворення значень з плаваючою комою в цілі числа, і встановлено, що операції із семи змінними мали ризик спричинити помилку операнда. Це призвело до додавання захисту для чотирьох змінних, що підтверджується у коді мовою Ada. Проте три змінні залишилися без захисту. Прямого обґрунтування цього рішення у вихідному коді не виявлено. З огляду на великий обсяг документації, властивий для будь-якого промислового застосування, таке припущення, хоча й було погоджене, фактично залишилося прихованим (хоча й ненавмисно) від будь-якої зовнішньої перевірки.

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

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

Хоча джерело помилки операнда було ідентифіковане, саме по собі воно не призвело до провалу місії. До відмови також спричинилася специфікація механізму обробки виключень. Згідно з вимогами системи, у випадку будь-якого виключення мало бути виконано: індикацію відмови на шині даних, збереження контексту відмови в енергонезалежній пам’яті EEPROM (яку було відновлено та зчитано для Ariane 501), а також зупинку процесора SRI.

Саме рішення припинити роботу процесора виявилося фатальним. Перезапуск був неможливим, оскільки визначення орієнтації після зупинки процесора є надто складним; таким чином, інерціальна референц-система ставала непридатною. Причина цього суворого підходу полягає у культурі програми Ariane, яка розглядала виключно випадкові апаратні збої. З цієї точки зору, механізми обробки виключень або помилок проєктувалися для випадкових відмов обладнання, які раціонально можна було обробити резервною системою.

Хоча відмова була спричинена систематичною помилкою у проєктуванні програмного забезпечення, існують механізми для пом’якшення подібних проблем. Наприклад, комп’ютери в межах SRI могли б продовжувати надавати найкращі оцінки необхідної інформації про орієнтацію. Викликає занепокоєння факт, що програмне виключення може (або навіть повинно) призводити до зупинки процесора під час керування критично важливим обладнанням місії. Втрата працездатної програмної функції є небезпечною, оскільки однакове програмне забезпечення використовується в обох системах SRI. У випадку Ariane 501 це призвело до відключення двох справних критичних блоків обладнання.

Первісна вимога щодо продовження роботи програмного забезпечення вирівнювання після старту була сформульована понад 10 років тому для попередніх моделей Ariane, аби врахувати малоймовірну ситуацію затримки у відліку, наприклад, між -9 секундами (початок режиму польоту в SRI Ariane 4) і -5 секундами, коли у ракеті ініціюються певні процеси, для скидання яких потрібні кілька годин. Обраний період у 50 секунд після початку режиму польоту базувався на часі, необхідному наземному обладнанню для відновлення повного контролю над ракетою у випадку затримки.

Ця особливість дала змогу для ранніх версій Ariane відновити відлік без очікування на нормальне вирівнювання, яке триває 45 хвилин і більше, що дозволяло використати коротке вікно запуску. Фактично ця можливість була застосована один раз — у 1989 році, під час польоту 33.

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

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

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

Основною темою у розробці Ariane 5 було зміщення акценту в бік пом’якшення випадкових відмов. Постачальник SRI лише дотримувався наданої йому специфікації, яка вимагала, щоб у разі будь-якого виявленого виключення процесор було зупинено. Втім, виключення, яке сталося, було спричинене не випадковою відмовою, а помилкою проєктування. Виключення було виявлене, але оброблене неналежним чином, оскільки було прийнято, що програмне забезпечення слід вважати правильним, доки не буде доведено протилежне. Комісія має підстави вважати, що такий підхід застосовується й в інших сферах розробки програмного забезпечення Ariane 5.

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

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

2.3 ПРОЦЕДУРИ ВИПРОБУВАННЯ ТА КВАЛІФІКАЦІЇ

Кваліфікація системи управління польотом для Ariane 5 відповідає стандартній процедурі та виконується на таких рівнях:

  • Кваліфікація обладнання
  • Кваліфікація програмного забезпечення (програмне забезпечення бортового комп’ютера)
  • Інтеграція етапів
  • Системні валідаційні випробування.

Логіка, яка застосовувалась, полягала у перевірці на кожному рівні того, що не могло бути досягнуте на попередньому рівні, забезпечуючи таким чином повне тестове покриття кожної підсистеми та інтегрованої системи.

У випадку з SRI тестування на рівні обладнання проводилося суворо щодо всіх впливів навколишнього середовища й навіть із перевищенням вимог, очікуваних для Ariane 5. Проте не було проведено жодного тесту для перевірки коректної роботи SRI під час відліку до старту, у польотний час та з урахуванням траєкторії Ariane 5.

Слід зазначити, що з фізичних причин неможливо протестувати SRI як «чорну скриньку» безпосередньо в умовах польоту, якщо тільки не здійснювати повністю реалістичний льотний експеримент. Водночас можна було провести наземні випробування шляхом введення змодельованих акселерометричних сигналів відповідно до прогнозованих параметрів польоту, паралельно використовуючи обертовий стенд для імітації кутових рухів ракети. Якби такий тест був проведений постачальником або в рамках приймальних випробувань, механізм відмови було б виявлено.

Основне пояснення відсутності цього тесту вже було наведене вище: специфікація SRI (яка мала слугувати вимоговим документом для цього обладнання) не містила даних траєкторії Ariane 5 як функціональної вимоги.

Комісія також відзначила, що системна специфікація SRI не вказує на експлуатаційні обмеження, які випливають з обраної реалізації. Таке декларування обмежень, яке повинно бути обов’язковим для кожного критично важливого пристрою, дозволило б виявити невідповідність траєкторії Ariane 5.

Іншою головною можливістю виявити механізм відмови заздалегідь були численні тести та моделювання, проведені у Функціональному імітаційному комплексі (ISF), розташованому на майданчику Промислового архітектора(Industrial Architect). Завданням випробувань у ISF є кваліфікація:

  • характеристики наведення, навігації та керування в усьому діапазоні польоту,
  • резервування датчиків, - спеціалізовані функції ступенів,
  • відповідність програмного забезпечення польоту (бортового комп’ютера) всьому обладнанню електричної системи керування польотом.

A large number of closed-loop simulations of the complete flight simulating ground segment operation, telemetry flow and launcher dynamics were run in order to verify :

  • номінальна траєкторія
  • траєкторії, погіршені відносно внутрішніх параметрів пускової установки
  • траєкторії, погіршені відносно атмосферних параметрів
  • відмови обладнання та подальша ізоляція та відновлення після відмови

У цих випробуваннях багато елементів обладнання були фізично присутні та задіяні, проте два SRI замінювалися спеціально розробленими програмними модулями. Деякі тести з відкритим контуром для перевірки сумісності бортового комп’ютера та SRI проводилися з використанням реального SRI. Вважається, що це були лише електричні інтеграційні випробування та «низькорівневі» (перевірка обміну даними по шині) тести на сумісність.

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

Ця процедура є особливо важливою для фінального системного тесту перед введенням системи в експлуатацію (випробування, проведені безпосередньо на ракеті-носії 501, тут не розглядаються, оскільки вони не були специфічними для кваліфікації електричної системи керування польотом).

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

Оскільки неможливо змоделювати великі лінійні прискорення ракети-носія по всіх трьох осях на випробувальному стенді (як зазначалося вище), існує два способи включити SRI у замкнене випробування:

  • A) Розмістити систему на тривісному динамічному столі (для збудження лазерних гіроскопів із кільцевим резонатором) і замінити аналоговий вихід акселерометрів (які неможливо збуджувати механічно) моделюванням через спеціальний тестовий вхідний роз’єм та електронну плату, розроблену для цієї мети. Такий підхід подібний до методу, що згадувався у зв’язку з можливістю випробувань на рівні обладнання.
  • B) Замінити обидва елементи — аналоговий вихід акселерометрів та лазерних гіроскопів із кільцевим резонатором — за допомогою спеціального тестового вхідного роз’єму сигналами, створеними шляхом моделювання.

Перший підхід, ймовірно, забезпечує точну імітацію (в межах смуги пропускання тривісного динамічного столу) і є досить дорогим; другий підхід дешевший, і його ефективність залежить головним чином від точності моделювання. У обох випадках велика частина електроніки та повне програмне забезпечення тестуються в реальному експлуатаційному середовищі.

Коли була визначена тестова філософія проєкту, було визнано важливість включення SRI у замкнений контур, і було прийнято рішення застосувати метод B, згаданий вище. На пізнішому етапі програми (у 1992 році) це рішення було змінено. Було вирішено не включати фактичні SRI у замкнений контур з наступних причин:

  • SRI слід вважати повністю кваліфікованими на рівні обладнання. – Точність навігаційного програмного забезпечення бортового комп’ютера критично залежить від точності вимірювань SRI. У ISF ця точність не могла бути досягнута електронікою, що генерувала тестові сигнали.
  • Імітація режимів відмов неможлива за допомогою реального обладнання, а лише за допомогою моделі.
  • Базовий період роботи SRI становить 1 мілісекунду, тоді як період моделювання в ISF — 6 мілісекунд. Це ускладнює інтерфейсну електроніку та може додатково знизити точність імітації.

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

Хоча бажана висока точність симуляції, у системних тестах ISF очевидно краще поступитися точністю, але досягти всіх інших цілей, зокрема підтвердити правильну інтеграцію системи та обладнання, такого як SRI. Точність системи керування може бути ефективно продемонстрована за допомогою аналізу та комп’ютерного моделювання.

У цьому контексті слід зазначити, що основним засобом запобігання відмовам є рев’ю, яке є невід’ємною частиною процесу проєктування та кваліфікації і проводиться на всіх рівнях за участю всіх основних партнерів проєкту (а також зовнішніх експертів). У програмі такого масштабу буквально тисячі проблем та потенційних відмов успішно обробляються у процесі рев’ю, і, очевидно, не легко виявити помилки програмного забезпечення типу тих, що стали первинною технічною причиною відмови Ariane 501.

Проте очевидно, що обмеження програмного забезпечення SRI не були повністю проаналізовані під час рев’ю, і не усвідомлювалось, що покриття тестів було недостатнім для виявлення таких обмежень. Також не були враховані можливі наслідки дозволу програмі вирівнювання працювати під час польоту. У цих аспектах процес рев’ю став співучасником відмови.

2.4 МОЖЛИВІ ІНШІ ОСЛАБЛЕННЯ ЗАЛУЧЕНИХ СИСТЕМ

Відповідно до свого мандату, Комісія дослідила можливі інші ослаблення, перш за все у системі керування польотом. Жодних ослаблень, пов’язаних із відмовою, виявлено не було, проте, незважаючи на обмежений час, Комісія провела детальний огляд системи керування польотом, спираючись на досвід, отриманий під час аналізу відмови.

Огляд охопив наступні області:

  • Конструкція електричної системи;
  • Вбудоване бортове програмне забезпечення у підсистемах, окрім Інерціальної Референсної Системи (SRI);
  • Бортовий комп’ютер та програмне забезпечення польотної програми.

Крім того, Комісія провела аналіз методів, застосованих у програмі розробки, зокрема щодо методології розробки програмного забезпечення.

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

3. ВИСНОВКИ

3.1 РЕЗУЛЬТАТИ

Рада дійшла таких висновків:

  • a) Під час підготовки до запуску та зворотного відліку не відбувалося жодних подій, пов’язаних із відмовою.
  • b) Метеорологічні умови на момент запуску були прийнятними та не вплинули на відмову. Жодні інші зовнішні фактори не були визнані релевантними.
  • c) Запалення двигунів та підйом були фактично номінальними, а впливи навколишнього середовища (шум і вібрації) на ракету-носій та корисне навантаження не мали відношення до відмови. Продуктивність рушіїв відповідала специфікації.
  • d) Через 22 секунди після H0 (команда на запалення головного кріогенного двигуна) у гідравлічному тиску актуаторів, що керують соплом головного двигуна, почали з’являтися коливання з частотою 10 Гц. Це явище є значущим і ще не повністю пояснене, проте після розгляду його не визнано релевантним до відмови.
  • e) Через 36,7 секунди після H0 (приблизно 30 секунд після підйому) комп’ютер резервної інерціальної системи, що перебував у режимі очікування для керування навігацією та орієнтацією, став непридатним. Це сталося через перевищення внутрішньою змінною, пов’язаною з горизонтальною швидкістю ракети, допустимого обмеження в програмному забезпеченні цього комп’ютера.
  • f) Приблизно через 0,05 секунди активна інерціальна система, ідентична резервній за апаратним та програмним забезпеченням, вийшла з ладу з тієї ж причини. Оскільки резервна система вже була непридатною, правильна навігаційна та орієнтаційна інформація більше не могла бути отримана, і втрата місії стала неминучою.
  • g) Унаслідок своєї відмови активна інерціальна система передавала головному комп’ютеру ракети в основному діагностичну інформацію, яка інтерпретувалась як польотні дані і використовувалась для розрахунків керування польотом.
  • h) На основі цих розрахунків головний комп’ютер наказав соплам прискорювачів, а трохи пізніше — і соплу головного двигуна, зробити значну корекцію за відхиленням орієнтації, яке фактично не виникало.
  • i) Відбулася різка зміна орієнтації, що призвела до руйнування ракети через аеродинамічні сили через 39 секунд після H0.
  • j) Руйнування було автоматично ініційоване після дезінтеграції, як передбачено конструкцією, на висоті 4 км та за 1 км від стартового майданчика.
  • k) Фрагменти розкидало на площі 5 × 2,5 км². Серед відновленого обладнання були два інерціальні системи, які були використані для аналізу.
  • l) Післяпольотний аналіз телеметричних даних зафіксував низку додаткових аномалій, що досліджуються, але не вважаються значущими для відмови.
  • m) Інерціальна система Ariane 5 є фактично спільною з системою, що наразі експлуатується на Ariane 4. Частина програмного забезпечення, яка спричинила зупинку комп’ютерів інерціальної системи, використовується до запуску для вирівнювання системи; у Ariane 4 також для швидкого повторного вирівнювання у разі затримки зворотного відліку. Ця функція повторного вирівнювання, яка не має практичного сенсу в Ariane 5, була збережена з міркувань уніфікації та дозволяла працювати приблизно 40 секунд після підйому.
  • n) Під час проєктування програмного забезпечення інерціальної системи для Ariane 4 і Ariane 5 було прийнято рішення, що необхідно захищати комп’ютер інерціальної системи від зупинки через надмірне значення змінної, пов’язаної з горизонтальною швидкістю, захист, який був реалізований для кількох інших змінних програмного забезпечення вирівнювання. При прийнятті цього рішення не було проаналізовано і повністю зрозуміло, які значення може приймати ця конкретна змінна під час роботи програмного забезпечення вирівнювання після підйому.
  • o) У польотах Ariane 4 з тим самим типом інерціальної системи таких відмов не було, оскільки траєкторія у перші 40 секунд польоту не дозволяє цій змінній досягти значення, що перевищує обмеження у програмному забезпеченні.
  • p) Ariane 5 має високе початкове прискорення та траєкторію, що призводить до швидкого зростання горизонтальної швидкості — у п’ять разів швидше, ніж у Ariane 4. Вища горизонтальна швидкість Ariane 5 протягом 40 секунд призвела до надмірного значення, що спричинило зупинку комп’ютерів інерціальної системи.
  • q) Метою процесу рев’ю, який залучає всіх основних партнерів програми Ariane 5, є підтвердження проєктних рішень та отримання кваліфікації для польоту. У цьому процесі обмеження програмного забезпечення вирівнювання не були повністю проаналізовані, і можливі наслідки його роботи під час польоту не були усвідомлені.
  • r) Специфікація інерціальної системи та випробування на рівні обладнання не включали конкретно траєкторійні дані Ariane 5. Внаслідок цього функція повторного вирівнювання не тестувалася в умовах моделюваного польоту Ariane 5, і проєктна помилка не була виявлена.
  • s) Технічно було б можливо включити майже всю інерціальну систему у загальні системні симуляції. З ряду причин було вирішено використовувати симульований вихід інерціальної системи, а не саму систему або її детальну симуляцію. Якби система була включена, відмову можна було б виявити.
  • t) Післяпольотні симуляції були виконані на комп’ютері з програмним забезпеченням інерціальної системи та зі змодельованим середовищем, включаючи фактичні траєкторійні дані польоту Ariane 501. Ці симуляції достовірно відтворили ланцюг подій, що призвів до відмови інерціальних систем.

3.2 ПРИЧИНА НЕСПРАВНОСТІ

Відмова Ariane 501 була спричинена повною втратою інформації про керування та орієнтацію через 37 секунд після початку послідовності запалення головного двигуна (30 секунд після підйому). Ця втрата інформації сталася через помилки у специфікації та проєктуванні програмного забезпечення інерціальної системи.

Розлогі рев’ю та випробування, проведені в рамках Програми розробки Ariane 5, не включали адекватного аналізу та тестування інерціальної системи або повної системи керування польотом, що могло б виявити потенційну відмову.

4. РЕКОМЕНДАЦІЇ

На основі проведеного аналізу та висновків, Комісія надає наступні рекомендації:

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

R2 – Підготувати випробувальний стенд із максимально можливою кількістю реального обладнання, вводити реалістичні вхідні дані та проводити повне, замкнене тестування системи. Повні симуляції повинні виконуватися до будь-якої місії. Потрібно досягти високого покриття тестами.

R3 – Заборонити будь-якому сенсору, наприклад інерціальній системі, припиняти передавати максимально точні дані («best effort»).

R4 – Організувати для кожного обладнання з ПЗ спеціальний огляд його кваліфікації. Промисловий архітектор має брати участь у цих оглядах та доповідати про проведене повне тестування системи з цим обладнанням. Усі обмеження щодо використання обладнання повинні бути чітко зафіксовані для Ревізійної комісії. Усі критичні програмні засоби зробити предметом конфігураційного контролю (CCI).

R5 – Провести огляд всього бортового програмного забезпечення (включаючи вбудоване), зокрема:

  • Ідентифікувати всі неявні припущення коду та документів обґрунтування щодо значень величин, що надаються обладнанням. Перевірити ці припущення щодо обмежень використання обладнання.
  • Перевірити діапазон значень будь-яких внутрішніх або комунікаційних змінних у ПЗ.
  • Проєктна команда повинна запропонувати рішення потенційних проблем ПЗ бортового комп’ютера, особливо щодо перемикання між комп’ютерами, і ці рішення повинні бути розглянуті групою зовнішніх експертів, яка доповідає до Кваліфікаційної комісії бортового комп’ютера.

R6 – Там, де технічно можливо, обмежувати винятки лише відповідними завданнями та передбачати резервні можливості.

R7 – Забезпечити надання більшої кількості даних телеметрії при відмові будь-якого компонента, щоб відновлення обладнання було менш критичним.

R8 – Переглянути визначення критичних компонентів із урахуванням відмов програмного походження (особливо одноточкових відмов).

R9 – Залучати зовнішніх учасників (поза проєктом) до перегляду специфікацій, коду та документів обґрунтування. Переконатися, що ці огляди оцінюють суть аргументів, а не лише перевірку виконання верифікацій.

R10 – Включити дані траєкторії у специфікації та вимоги до випробувань.

R11 – Переглянути покриття тестами існуючого обладнання та розширити його там, де це необхідно.

R12 – Надати документам обґрунтування таку ж увагу, як і коду. Поліпшити методику підтримки узгодженості коду та його обґрунтувань.

R13 – Створити команду для підготовки процедури кваліфікації програмного забезпечення, запропонувати суворі правила підтвердження такої кваліфікації та забезпечити високоякісне специфікаціювання, верифікацію та тестування ПЗ у програмі Ariane 5. Розглянути можливість залучення зовнішніх експертів RAMS.

R14 – Розглянути більш прозору організацію співпраці між партнерами програми Ariane 5. Необхідна тісна інженерна взаємодія з чіткими повноваженнями та відповідальністю для досягнення узгодженості системи та простих, зрозумілих інтерфейсів між партнерами.

- КІНЕЦЬ -