Уроки, извлечённые из управления требованиями: полёт 501 Ariane 5

Катастрофа рейса 501 Ariane 5 показывает, почему перед повторным использованием без изменений требований, инженерных решений и испытаний из прошлых проектов всегда стоит дважды подумать. 

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

Рейс 501 Ariane 5 стал первым запуском европейской ракеты Ariane 5 4 июня 1996 года. В ракете повторно использовалась часть программного обеспечения инерциальной системы отсчета от Ariane 4 — более ранней европейской ракеты, где это ПО успешно работало. Но Ariane 5 следовала по другому профилю полета, одно из значений вышло за диапазон, который ожидало программное обеспечение, и ракета была уничтожена менее чем через минуту после старта.

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

Ключевые выводы

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

Что произошло при запуске Ariane 5

4 июня 1996 года Ariane 5 совершила свой первый полет с космодрома Куру во Французской Гвиане, неся четыре исследовательских спутника Cluster для Европейского космического агентства. Миссия длилась меньше минуты. Примерно через тридцать семь секунд после старта ракета отклонилась от запланированной траектории и была уничтожена.

Проблема исходила из инерциальной системы отсчета, которая передавала данные об ориентации и скорости на бортовой компьютер ракеты. Ariane 5 повторно использовала программное обеспечение от Ariane 4, включая процедуру выравнивания, которая оставалась активной около 40 секунд после запуска. Эта процедура работала в Ariane 4, но Ariane 5 следовала по другому профилю полета.

Из-за этого отличающегося профиля последовательно и очень быстро произошло следующее:

• Значение горизонтальной скорости стало больше, чем ожидало программное обеспечение.
• ПО попыталось преобразовать это значение из 64-битного числа с плавающей запятой в 16-битное знаковое целое число, но оно уже не помещалось в этот формат.
• Произошло переполнение при преобразовании, и инерциальная система отсчета восприняла это как ошибку и отключилась.
• Резервная система работала на том же программном обеспечении и отключилась по той же причине.
• Не имея корректных полетных данных, бортовой компьютер использовал вместо них диагностические данные, выдал неверные команды управления полетом, и ракета была уничтожена.

Именно поэтому этот случай полезен для управления требованиями. Повторно использованное ПО уже работало ранее, но несло в себе допущение из предыдущей ракеты: что это значение останется в безопасном диапазоне. В Ariane 5 контекст вокруг этого допущения изменился, поэтому его нужно было явно видеть и заново проверить в новой системе.

Этот пример напоминает, что повторно используемая инженерная работа все равно требует одной простой проверки: остаются ли допущения, лежащие в ее основе, верными в новой системе?

Чему аппаратные команды могут научиться из случая Ariane 5

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

Это нормальная инженерная практика. Повторное использование помогает командам работать быстрее. Важный шаг здесь — убедиться, что требование, допущение и проверка верификации по-прежнему соответствуют новой системе.

Пересматривайте повторно используемые требования

Требование, которое работало в одном продукте, не следует автоматически считать действительным и в следующем. Формулировка может по-прежнему выглядеть корректной, но рабочие условия вокруг нее могли измениться. Например, ограничение по току, тепловой диапазон или интерфейсное ограничение могут быть безопасными в одном проекте, но потребовать пересмотра в другом. Перед повторным использованием требования команда должна проверить, работает ли новый продукт в рамках тех же допущений.

Связывайте допущения с процедурами верификации

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

Пересматривайте тесты при изменении требований

Тест-кейс, успешно пройденный в предыдущем проекте, не всегда подтверждает то же самое в следующем. Если требование изменилось или изменилась система вокруг него, связанную процедуру испытаний, возможно, тоже придется изменить. Это особенно важно, когда команды повторно используют тест-кейсы, критерии приемки или доказательства соответствия.

Как помогает связанный процесс работы с требованиями

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

Именно это важнее всего, когда что-то меняется. Повторно используемое требование может по-прежнему выглядеть правильным, но допущение, лежащее в его основе, может уже не соответствовать новому продукту. Тест может по-прежнему существовать, но уже не проверять нужное условие.

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

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

Остаются ли старые допущения в вашем проекте верными?

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

Полезный вопрос заключается в том, что именно изменилось вокруг этой повторно используемой работы:

• Изменился ли рабочий диапазон? 
• Нужно ли пересмотреть тест? 
• По-прежнему ли действуют допущения, лежащие в основе исходного решения?

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

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

Упростите проверку и повысьте доверие к решениям о повторном использовании с помощью инструмента управления требованиями, к которому есть доступ у всей вашей команды.

Начните работу с Requirements Portal →

Часто задаваемые вопросы

Может ли повторное использование инженерных наработок стать рискованным?

Повторное использование инженерных наработок может стать рискованным, если контекст продукта изменился, а исходные допущения, рабочие пределы или проверки верификации не были пересмотрены заново. Такая работа может по-прежнему выглядеть корректной, но условия, которые делали ее обоснованной в предыдущем проекте, могут уже не действовать.

Что инженерам следует проверить перед повторным использованием требования, теста или проектного решения?

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

Как трассируемость помогает при повторном использовании требований?

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