Авария «Ариан-5» 4 июня 1996. Подробности программной ошибки.

Теги:космос
 
+
-
edit
 

Balancer

администратор
★★★★★
Чем дальше, тем эта тема всё больше работает по принципу «испорченного телефона». Так что сделаю отдельную тему, чтобы можно было кидаться только ссылкой.

4 июня 1996 г. был произведен первый запуск ракеты-носителя Ariane 5 – детища и гордости Европейского Сообщества. Уже через неполные 40 сек. все закончилось взрывом. Автоподрыв 50-метровой ракеты произошел в районе ее запуска с космодрома во Французской Гвиане. За предшествующие годы ракеты серии Ariane семь раз терпели аварии, но эта побила все рекорды по вызванным ею убыткам. Только находившееся на борту научное оборудование потянуло на пол-миллиарда долларов, не говоря о прочих разноообразных издержках; а астрономические цифры "упущенной выгоды" от несостоявшихся коммерческих запусков и потеря репутации надежного перевозчика в очень конкурентном секторе мировой экономики ("стоимость рынка" к 2000 г. должна превысить 60 млрд. долл.) с трудом поддаются оценке. Небезынтересно отметить, что предыдущая модель – ракета Ariane 4 – успешно запускалась более 100 раз.

Буквально на следующий день Генеральный директор Европейского Космического Агенства (ESA) и Председатель Правления Французского Национального Центра по изучению Космоса (CNES) издали распоряжение об образовании независимой Комиссии по Расследованию обстоятельств и причин этого чрезвычайного происшествия, в которую вошли известные специалисты и ученые изо всех заинтересованных европейских стран. Возглавил Комиссию представитель Французской Академии Наук профессор Жак-Луи Лион (Jacques-Louis Lions). Кроме того, был сформирован специальный Технический Комитет из представителей заказчиков и подрядчиков, ответственных за производство и эксплуатацию ракеты, в чью обязанность было вменено незамедлительно предоставлять Комиссии всю необходимую информацию.

13 июня 1996 г. Комиссия приступила к работе, а уже 19 июля был обнародован ее исчерпывающий доклад, который сразу же стал доступен в Сети [1]. Что же касается информации, которую – при участии нескольких институтов – осмысляла Комиссия, то она состояла из телеметрии, траекторных данных, а также оптических наблюдений за ходом полета. Были собраны (что само по себе было непросто, так как взрыв произошел на высоте приблизительно 4 км, и осколки были рассеяны на площади около 12 кв. км. в саванне и болотах) и изучены части ракеты и оборудования. Кроме того, были заслушаны показания многочисленных специалистов и изучены горы производственной и эксплуатационной документации.

Технические подробности аварии

Положение и ориентация ракеты-носителя в пространстве измеряются Навигационной Системой (Inertial Reference Systems – IRS), составной частью которой является встроенный компьютер, вычисляющий углы и скорости на основе информации от бортовой Инерциальной Платформы, оборудованной лазерными гироскопами и акселерометрами. Данные от IRS передаются по специальной шине на Бортовой Компьютер (On-Board Computer – OBC), который обеспечивает необходимую для реализации программы полета информацию и непосредственно – через гидравлические и сервоприводы – управляет твердотопливными ускорителями и криогенным двигателем типа Вулкан (Vulkain).

Как обычно, для обеспечения надежности Системы Управления Полетом используется дублирование оборудования. Поэтому две системы IRS (одна – активная, другая – ее горячий резерв) с идентичным аппаратным и программным обеспечением функционируют параллельно. Как только бортовой компьютер OBC обнаруживает, что "активная" IRS вышла из штатного режима, он сразу же переключается на другую. Впрочем, и бортовых компьютеров тоже два.

Теперь, следуя Докладу Комиссии [1], проследим все значимые фазы развития процесса, оказавшегося в конце концов аварийным. Момент старта обозначим H0 – это и будет точка отсчета для всех событий, хотя отслеживать их мы будем в обратном – начиная с момента саморазрушения системы – порядке. Для полноты картины упомянем, что предшествующие старту операции происходили в нормальном режиме вплоть до момента H0-7 минут, когда было зафиксировано нарушение "критерия видимости". Поэтому старт был перенесен на час; в H0 = 9 час. 33 мин. 59 сек. местного времени "окно запуска" было вновь "поймано" и был, наконец, осуществлен сам запуск, который и происходил штатно вплоть до момента H0+37 сек. В последующие секунды произошло резкое отклонение ракеты от заданной траектории, что и закончилось взрывом. Итак:
  • в момент H0+39 сек. из-за высокой аэродинамической нагрузки вследствие превышения "углом атаки" критической величины на 20 градусов произошло отделение стартовых ускорителей ракеты от основной ее ступени, что и послужило основанием для включения Системы Автоподрыва ракеты;
  • изменение угла атаки произошло по причине нештатного вращения сопел твердотопливных ускорителей;
  • такое отклонение сопел ускорителей от правильной ориентации вызвала в момент H0 + 37 сек. команда, выданная Бортовым Компьютером на основе информации от активной Навигационной Системы (IRS 2). Часть этой информации была в принципе некорректной: то, что интерпретировалось как полетные данные, на самом деле являлось диагностической информацией встроенного компьютера системы IRS 2;
  • встроенный компьютер IRS 2 передал некорректные данные, потому что диагностировал нештатную ситуацию, "поймав" исключение (exception), выброшенное одним из модулей программного обеспечения;
  • при этом Бортовой Компьютер не мог переключиться на резервную систему IRS 1, так как она уже прекратила функционировать в течение предшествующего цикла (занявшего 72 мсек.) – по той же причине, что и IRS 2;

исключение, "выброшенное" одной из программ IRS, явилось следствием выполнения преобразования данных из 64-разрядного формата с плавающей точкой в 16-разрядное целое со знаком, что привело к "Operand Error";
  • ошибка произошла в компоненте ПО, предназначенном исключительно для выполнения "регулировки" Инерциальной Платформы. Причем – что звучит парадоксально, если не абсурдно – этот программный модуль выдает значимые результаты только до момента H0 + 7 сек. отрыва ракеты со стартовой площадки. После того, как ракета взлетела, никакого влияния на полет функционирование данного модуля оказать не могло;
  • однако, "функция регулировки" действительно должна была (в соответствии с установленными для нее требованиями) действовать еще 50 сек. после инициации "полетного режима" на шине Навигационной Системы (момент H0-3 сек.), что она с усердием дурака, которого заставили богу молиться, и делала;
  • ошибка "Operand Error" произошла из-за неожиданно большой величины BH (Horizontal Bias – горизонтальный наклон), посчитанной внутренней функцией на основании величины "горизонтальной скорости", измеренной находящимися на Платформе датчиками. Величина BH служила индикатором точности позиционирования Платформы;
  • величина BH оказалась много больше, чем ожидалось потому, что траектория полета Ariane 5 на ранней стадии существенно отличалась от траектории полета Ariane 4 (где этот программный модуль использовался ранее), что и привело к значительно более высокой "горизонтальной скорости".


Финальным же действием, имевшим фатальные последствия, стало прекращение работы процессора; соответственно, вся Навигационная Система перестала функционировать. Возобновить же ее действия оказалось технически невозможно.

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

Причины и истоки аварии

Прежде всего проследим, откуда взялось первоначальное требование на продолжение выполнения операции регулировки после взлета ракеты. Оказывается, оно было заложено более чем за 10 лет до рокового события, когда проектировались еще ранние модели серии Ariane. При некотором (весьма маловероятном!) развитии событий взлет мог быть отменен буквально за несколько секунд до старта, например в промежутке H0-9 сек., когда на IRS запускался "полетный режим", и H0-5 сек., когда выдавалась команда на выполнение некоторых операций с ракетным оборудованием. В случае неожиданной отмены взлета необходимо было быстро вернуться в режим "обратного отсчета" (countdown) – и при этом не повторять сначала все установочные операции, в том числе приведение к исходному положения Инерциальной Платформы (операция, требующая 45 мин. – время, за которое можно потерять "окно запуска").

Было обосновано, что в случае события отмены старта период в 50 сек. после H0-9 будет достаточным для того, чтобы наземное оборудование смогло восстановить полный контроль за Инерциальной Платформой без потери информации – за это время Платформа прекратит начавшееся было перемещение, а соответствующий программный модуль всю информацию о ее состоянии зафиксирует, что поможет оперативно возвратить ее в исходное положение (напомним, что все это в случае, когда ракета продолжает находиться на месте старта). И действительно, однажды, в 1989 г., при старте под номером 33 ракеты Ariane 4, эта особенность была с успехом задействована.

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

В конце концов, было бы странно, если бы тривиальная ошибка переполнения (даже если она и возникла) была бы столь фатальной, что с ней невозможно бороться. Почему же программный код (написанный на таком оснащенном всеми необходимыми для обеспечения надежности средствами языке, как Ада) оказался незащищеным до такой степени, что наступили столь катастрофические последствия?

Расследование показало, что в данном программном модуле присутствовало целых семь переменных, вовлеченных в операции преобразования типов. Оказалось, что разработчики проводили анализ всех операций, способных потенциально генерировать исключение, на уязвимость. И это было их вполне сознательным решением добавить надлежащую защиту к четырем переменным, а три – включая BH – оставить незащищенными. Основанием для такого решения была уверенность в том, что для этих трех переменных возникновение ситуации переполнения невозможно в принципе. Уверенность эта была подкреплена расчетами, показывающими, что ожидаемый диапазон физических полетных параметров, на основании которых определяются величины упомянутых переменных, таков, что к нежелательной ситуации привести не может. И это было верно – но для траектории, рассчитанной для модели Ariane 4. А ракета нового поколения Ariane 5 стартовала по совсем другой траектории, для которой никаких оценок не выполнялось. Между тем она (вкупе с высоким начальным ускорением) была такова, что "горизонтальная скорость" превзошла расчетную (для Ariane 4) более чем в пять раз.

Но почему же не была (пусть в порядке перестраховки) обеспечена защита для всех семи, включая BH, переменных? Оказывается, для компьютера IRS была продекларирована максимальная величина рабочей нагрузки в 80%, и поэтому разработчики должны были искать пути снижения излишних вычислительных издержек. Вот они и ослабили защиту там, где теоретически нежелательной ситуации возникнуть не могло. Когда же она возникла, то вступил в действие такой механизм обработки исключительной ситуации, который оказался совершенно неадекватным.

Этот механизм предусматривал следующие три основных действия. Прежде всего, информация о возникновении нештатной ситуации должна быть передана по шине на бортовой компьютер OBC; параллельно она – вместе со всем контекстом – записывалась в перепрограммируемую память EEPROM (которую во время расследования удалось восстановить и прочесть ее содержимое), и наконец, работа процессора IRS должна была аварийно завершиться. Последнее действие и оказалось фатальным – именно оно, случившееся в ситуации, которая на самом деле была нормальной (несмотря на сгенерированное из-за незащищенного переполнения программное исключение), и привело к катастрофе.

Осмысление

Произошедшая с Ariane 5 катастрофа имела исключительно большой резонанс – и по причине беспрецедентных материальных потерь, и вследствие очень оперативного расследования, характеризовавшегося к тому же открытостью результатов (впервые такая практика публичности была опробована при расследовании причин аварии космического корабля Challenger 1986 г.). Сразу стало очевидным, что данному событию суждено войти в историю не только космонавтики, но и программной инженерии. Поэтому неудивительно, что авария послужила поводом для оживленной дискуссии, в которой приняли участие многие известные специалисты.

Ж.-М. Жезекель (J.-M. Jezequel) и Б.Мейер (B.Meyer) [2] пришли к совершенно однозначному выводу: допущенная (и так и не выявленная) программная ошибка носит, по их мнению, чисто технический характер и коренится в некорректной практике повторного использования ПО. Более точная формулировка: роковую роль сыграло отсутствие точной спецификации повторно-используемого модуля. Расследование показало, что обнаружить требование, устанавливающее максимальную величину BH (вмещающуюся в 16 битов), можно было с большим трудом: оно затерялось в приложениях к основному спецификационному документу. Мало того, в самом коде на этот счет не было никаких комментариев, не говоря уже о ссылке на документ с обоснованием этого требования.

В качестве панацеи в такого рода ситуациях авторы предложили задействовать принцип "Контрактного Проектирования" (что и неудивительно, ибо его разработчиком как раз и является Мейер [3]). Именно "контракт" в духе языка Eiffel, явным образом (с помощью пред- и пост-условий) устанавливающий для любого программного компонента ограничения на входные и выходные параметры, и мог бы предотратить катастрофическое развитие событий. Был приведен и набросок такого контракта:

code eiffel
  1. convert (horizontal_bias:INTEGER): INTEGER is
  2.    require
  3.      horizontal_bias <= Maximum_bias
  4.        do
  5.        ...
  6.      ensure
  7.    ...
  8. end


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

Однако, самым важным достоинством использования контрактных механизмов является, по мнению авторов, явное присутствие легко понимаемых и при необходимости верифицируемых ограничений как в документации, так и в коде. При работе над сложными проектами типа Ariane именно контракты могли бы выступать в качестве опорных ориентиров для групп качества "QA Team", чья задача – выполнять систематический мониторинг ПО на предмет соответствия требованиям. Авторы с сожалением заключают, что контрактные механизмы никак не получат должного распространения в современной практике. Более того, положение только усугубляется: например, в Java даже исчезла присутствовавшая в языке Cи скромная по возможностям инструкция "assert". В составной части CORBA – языке IDL (Interface Definition Language), предназначенном обеспечить полномасштабное повторное использование компонентов в распределенной среде, отсутствует какой-либо механизм спецификации семантики. То же относится и к ActiveX. Авторы заключают: без полной и точной спецификации, основанной на пред- и пост-условиях и инвариантах, "повторное использование программных компонентов – совершенное безрассудство".

Эта точка зрения вызвала многочисленные отклики. Хотя полезность использования контрактных механизмов никто не оспаривал, все же взгляд авторов многим показался упрощенным. Наиболее обстоятельный критический разбор их статьи выполнил сотрудник Locheed Martin Tactical AirCraft Systems, известный специалист в области разработки ответственных систем Кен Гарлингтон (Ken Garlington) [4]. Он начал с того, что указал на ошибку в приведенном наброске контракта, где предполагается, что BH преобразуется не из вещественного (как то было в реальности) числа, а из целого. Показательно, пишет Гарлингтон, что он оказался первым, кто обратил внимание на столь очевидный прокол, а ведь статью читали и публично обсуждали многие квалифицированные специалисты. С тем же успехом (а точнее неуспехом) могла пройти мимо этого дефекта и "QA-team". Так что даже точная спецификация сама по себе не панацея. Гарлингтон также подробно разобрал нетривиальные проблемы, возникающие при написании не "наброска", а действительно полной спецификации контракта для данной конкретной ситуации.

Вывод Гарлингтона вполне отвечает здравому смыслу: проблема носит комплексный характер и обусловлена прежде всего объективной сложностью систем типа Ariane. Соответственно, одним лекарством болезнь, приводящая к появлению ошибок в ПО, вылечена быть не может. Хотя то, что процесс мониторинга спецификаций, кода и документов с обоснованием проектных решений при разработке ПО для Ariane 5, оказался неадекватен, отметила и Комиссия по расследованию аварии. В частности, подчеркнуто, что к процессу контроля не привлекались специалисты из организаций, независимых как от заказчика, так и от подрядчика системы, что нарушило принцип разделения исполнительных и контрольных функций.

Большие претензии были предъявлены не только к процессу тестирования как таковому, но и к самой его стратегии. На этапе тестирования и отладки системы было технически возможно в рамках интегрального моделирования процесса полета исследовать все аспекты работы IRS, что позволило бы почти гарантированно выявить ошибку, приведшую к аварии. Однако, вместо этого при моделировании работы всего комплекса IRS рассматривалась как черный ящик, заведомо выдающий то, что ожидается. Почему? А зачем тестировать то, что успешно работало в течение многих лет?!

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

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

В данном же случае, возникла систематическая программная ошибка; "систематическая" – в том смысле, что при повторении тех же входных условий, она обязательно возникнет вновь, ибо – тавтология здесь уместна – запрограммирована. Вот почему подключение резервной Навигационной Системы ничего не дало: ведь ПО на нем исполнялось то же самое, соответственно и обе IRS, и дублирующие друг друга Бортовые Компьютеры с неотвратимостью натыкались на ту же ситуацию и с покорностью обреченных на заклание овец шли к катастрофе. Очевидно, что необходимо по крайней мере отнять у "врача" пистолет: прекращать функционирование аппаратуры при возникновении программного "исключения" целесообразно лишь после комплексного анализа ситуации, но никак не автоматически.

В контексте данной статьи интересно мнение главного редактора журнала "Automated Software Engineering" Башара Нузейбеха (Bashar Nuseibeh) [5], который, дав обзор разных точек зрения на причины аварии и придя к выводу, что "все правы", связал все-таки катастрофу Ariane 5 с более общими проблемами разработки программных систем. Он отметил, в частности, что современные тенденции в программной инженерии, связанные с разделением интересов вовлеченных в разработку независимо работающих персонажей (что связано с широким внедрением таких подходов, как объектно-ориентированные и компонентные технологии) не получают надлежащего балансирующего противовеса в виде менеджмента, способного координировать всю работу на должном уровне. Эта тема заслуживает дальнейшего обсуждения, но сначала обратимся к еще одной печально знаменитой истории.

// Мифы о безопасном ПО: уроки знаменитых катастроф - № 06, 1998 | Открытые системы | Издательство «Открытые системы»
 
 

au

   
★★☆
Жезекель Мейер сделали совершенно корректные выводы как и почему был допущен дефект в системе. Это самое важное, потому что проверять правильность чужой программы (и вообще подобного креатива) намного труднее, чем её создавать; соответственно, логично направить максимальные усилия именно на недопущение дефектов. И потому если ради достижения надёжности такого эпического проекта нужно использовать более мощный процессор (или добавить ему памяти), то системные инженеры должны были просто потребовать этого. Вместо рассуждений о неизбежности компромисных решений, всегда можно выяснить цену вопроса, и если это <0.1% от стоимости проекта (это психологический барьер), то это уже просто не вопрос. В данном случае это <$5М — за эти деньги можно легко решить проблему недостатка мощности процессора (как вот насчёт такого компромиса?!). И они же, кстати, должны были не допустить слепого переноса алгоритмов (даже не программ!) с старой системы на новую. НАСА нынче пришло к тому, что старые (проверенные) компоненты требуется рассматривать наравне с новыми, т.е. понятие "проверенный" лишается смысла за рамками проекта, в котором проводилась проверка. К алгоритмам, и тем более программам, это правило применимо в первую очередь из-за неизменной сложности (если не запутанности) систем. И эта рукотворная сложность, системные дефекты, и failure of imagination — это виды с разных точек зрения на грабли под названием "человеческий фактор".

Вот живой пример из текста — обрыдаться автору нужно:
Принцип действий здесь "простой, как мычание", исходящий из критериев безусловного обеспечения максимальной надежности: отключать допустившее сбой оборудование и тут же задействовать резервный блок: вероятность того, что этот блок также выдаст случайный сбой, да еще в той же ситуации, для надлежаще спроектированных и отлаженных аппаратных систем чрезвычайна мала.
 
Руководствуясь этим порочным принципом, два идентичных исправных компа с идентичным дефектным софтом, одинаково отработают любой дефект в софте, и потому заявление про чрезвычайно малую вероятность совместного сбоя заведомо бессмысленно. Именно поэтому для резервных компов Шаттла софт писали две разные группы. И даже они говорят что считают комп Шаттла бездефектным с высокой вероятностью, но не абсолютно. И поскольку никто никогда не даст гарантии что дефектов в сложной системе абсолютно нет, единственный путь к этому — упрощение системы до уровня, когда она полностью помещается в одной голове. Тогда не только один человек — хотя бы каждый системный инженер, который пишет спецификации, — сможет принимать решения в контексте всей системы, но и заметить допущенный дефект. Естесственно, это невозможно без жёсткой иерархии с предельно простыми интерфейсами между её уровнями. Но на каждом отдельном уровне это не только возможно, но и необходимо, если не хочется проводить рекордно быстрые расследования по угробленному проекту за полмиллиарда баксов. Иначе говоря, системный анализ и синтез — это фундаментальный элемент проекта. Любые ошибки, сделанные на этом уровне, имеют наибольшие шансы оказаться фатальными, что и получилось с Ариан-5. Нузейбех неправ — у допущенных конкретных ошибок есть конкретные имена и фамилии.

Цитата из одной умной тематической книжки:
Re-using old software on new systems does not guarantee safety and may lead to awkward and dangerous designs. ‘Safety is a quality of the system in which the software is used; it is not a quality of the software itself.’
 
То же можно сказать и о любом другом элементе системы на любом уровне её иерархии.
 
+
-
edit
 

Wyvern-2

координатор
★★★★★
В той статье (я ее читал в бумажном журнале) есть более интересные (и страшные) вещи, чем несчастный Ариан

Ник
Жизнь коротка, путь искусства долог, удобный случай мимолетен, опыт обманчив.... Ἱπποκράτης  
+
-
edit
 

dmitrik

новичок

[Поправил формат (похоже авиабаза не любит * в начале строки)]

Я в свое время купил Мейеровскую книжку "Object Oriented Software Construction".
Он там эту несчастную Ариану во все дыры сует.
Мне стало интересно и я почитал первоисточники. Вот кстати:

Официальный репорт. На сайте ESA не нашел но вот копия:

Ariane 501 Inquiry Board report - Wikisource

Ariane 501 Inquiry Board report
From Wikisource
Jump to: navigation,
search
Ariane 501 Inquiry Board reportAriane 501 Inquiry Board — Prof. Jacques-Louis Lions (Chairman)
related portals: Miscellaneous material.


// Дальше —
en.wikisource.org
 


Черная магия... (Бертран Мейер)

The lessons of Ariane

Home page for object technology, Eiffel, software reuse, components, O-O training and consulting, with extensive online documentation,tutorials, articles and manuals.

// archive.eiffel.com
 

и полное ее разоблачение... (Кен Гарлингтон)


По поводу настоящих причин аварии:
Из официального отчета:

"However, no test was performed to verify that the SRI would behave correctly when being subjected to the count-down and flight time sequence and the trajectory of Ariane 5."

Они не разу не прогнали гироплатформу по предстоящему полетному заданию!!! Что тут еще сказать?! (имеется в виду до запуска. Каким-то образом они смогли это сделать через буквально 2 дня после и надо-же какая неожиданность - оба компьютера хором слетели).

"There is no evidence that any trajectory data were used to analyse the behaviour of the unprotected variables, and it is even more important to note that it was jointly agreed not to include the Ariane 5 trajectory data in the SRI requirements and specification."

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

"It should be noted that for reasons of physical law, it is not feasible to test the SRI as a "black box" in the flight environment, unless one makes a completely realistic flight test, but it is possible to do ground testing by injecting simulated accelerometric signals in accordance with predicted flight parameters, while also using a turntable to simulate launcher angular movements. Had such a test been performed by the supplier or as part of the acceptance test, the failure mechanism would have been exposed.

"The main explanation for the absence of this test has already been mentioned above, i.e. the SRI specification (which is supposed to be a requirements document for the SRI) does not contain the Ariane 5 trajectory data as a functional requirement."
Физически Невозможно было протестировать гироплатформу в полете но можно было бы моделировать внешние сигналы в соответствии с ожидаемыми параметрами полета при этом поставив платформу на поворотный стол чтобы моделировать угловые движения ракеты. Если бы такое испытание было бы произведено, ошибку бы обнаружили. Основное объяснение почему этого сделано не было, как уже было сказано, это отсутствие данных о траектории Ариан-5 в функциональных требованиях.

"The supplier of the SRI was only following the specification given to it, which stipulated that in the event of any detected exception the processor was to be stopped."
Поставщик только выполнял спецификацию в соответствии с которой в случае любой ошибки процессор должен быть остановлен.


По поводу Мейера: он просто пропиарился на чужом горе. Я полностью согласен с Кеном. В данном случае его Эйфель не помог бы никаким боком, потому как:
Решение не включать проверку диапазона для конкретной переменной было сделано намеренно, на неслоьких уровнях. Нет никаких оснований предполагать что аналогичное решение не было бы сделано при написании кода на Эйфеле.
Документация прошла соответствующую ревизию при адаптации софта для Ариан-5. Несоответствие благополучно проморгали, а точнее у проверяющих не было достаточно информации об изменениях в программе полета Ариан-5 по сравнению с Ариан-4. Точно также посмотрели бы на пред-условие в коде, сказали бы "ну да вроде все разумно" и пошли бы дальше.
При тестировании (до запуска) переполнения не произошло ни разу. Соответственно не произошло бы и нарушения пред-условий в Эйфеле.
В релизе проверки скорее всего были бы отключены, посему результат был бы тот же.
Если бы даже они не были отключены, то что бы это дало? Какая разница по какой причине слетела программа - по переполнению или по нарушению предусловия? и в том и в другом случае управление передается обработчику ошибок, который и слил воду в полном соответствии с ТЗ. Может в ТЗ надо было чего подправить?

И вообще про Эйфель: он много говорит но мало делает. Там нет самого главного: статической проверки контрактов. Если бы она там была И если бы написали правильные контракты (диапазон допустимых значений) на входные параметры, то был бы шанс несоответствия отловить. А так это все полезно конечно, но ничего революционного в этом нет.
Чтобы сделать нормальный DbC нужна систама доказательсва теорем, и все это очень не просто хотя попытки имеются, наиболее коммерчески известный - это SPARK, урезанный вариант Ады со статической верификацией, на нем написан софт для C-130
 
Это сообщение редактировалось 14.03.2007 в 05:09
+
-
edit
 

Mishka

модератор
★★★
Ребята, контракты с пост- и предикатами — они хороши. Но в умелых руках они не работают. Наличие большого числа предикатов приводит к тому, что пишутся они автоматически, при этом код после этих предикатов вовсе не покрывает всех возможных вариантов допущенных величин.
 
+
-
edit
 

haleev

втянувшийся

>> За предшествующие годы ракеты серии Ariane семь раз терпели аварии, но эта побила все рекорды по вызванным ею убыткам. Только находившееся на борту научное оборудование потянуло на пол-миллиарда долларов, не говоря о прочих разноообразных издержках; а астрономические цифры "упущенной выгоды" от несостоявшихся коммерческих запусков и потеря репутации надежного перевозчика в очень конкурентном секторе мировой экономики ("стоимость рынка" к 2000 г. должна превысить 60 млрд. долл.) с трудом поддаются оценке.

Хых... О стоимости программных ошибок: стоимость Гюйгенса озвучивалась как 2.5 миллиарда евро. Из за программной ошибки едва не половина передававшейся зондом информации была утеряна. Ошибка состояла в том, что не был включен второй передатчик и данные передавались только по одному каналу.
Кто-нибудь знает подробности об этой ошибке?
Моё предположение (ничем не подтверждённое, кроме своего программистского опыта), что не второй передатчик забыли включить, а первый включили два раза.
Ctrl+C -> Ctrl+V.
Предикаты от такого спасут?
(это не ирония, мне интересно чем с "великой китайской технологией" бороться можно)
 
Это сообщение редактировалось 12.03.2007 в 12:19
RU Серокой #12.03.2007 12:38  @haleev#12.03.2007 12:10
+
-
edit
 

Серокой

координатор
★★★★
haleev> Ctrl+C -> Ctrl+V.

Кстати, да, кто-то предлагал исключить функции копирования-вставки из редакторов программного текста. )
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©  
RU Balancer #12.03.2007 20:24  @Серокой#12.03.2007 12:38
+
-
edit
 

Balancer

администратор
★★★★★
Серокой> Кстати, да, кто-то предлагал исключить функции копирования-вставки из редакторов программного текста. )

Чарльз Мур говорил, что в редакторе настоящего программиста должна отсутствовать функция копирования блоков :)
 

au

   
★★☆

Huygens (spacecraft) - Wikipedia, the free encyclopedia

Huygens (spacecraft)
From Wikipedia, the free encyclopedia
  (Redirected from Huygens probe)
Jump to: navigation,
search
Huygens probe


// Дальше —
en.wikipedia.org
 

The loss of Channel A means only 350 pictures were received instead of the 700 planned. Also all Doppler radio measurements between Cassini and Huygens were lost. Doppler radio measurements of Huygens from Earth were made, though not as accurate as expected measurement that Cassini would have made; when added to accelerometer sensors on Huygens and VLBI tracking of the position of the Huygens probe from Earth, reasonably accurate wind speed and direction measurements can still be derived.

Huygens

Huygens Named after Dutch astronomer Christiaan Huygens , the Huygens space probe is a saucer-shaped probe designed by the European Space Agency to

// www.answers.com
 

As it turned out, Cassini never listened to channel A because of a software commanding error. The receiver on the orbiter was never commanded to turn on, according to officials with the European Space Agency. ESA announced that the program error was a mistake on their part, the missing command was part of a software program developed by ESA for the Huygens mission and that it was executed by Cassini as delivered.

Не знал, однако! Перлы вон аж куда уже слетали. :P
 
+
-
edit
 

Balancer

администратор
★★★★★
Вот ещё подробный материал.

Космическая ошибка: $370 000 000 за Integer overflow

Пуск. 37 секунд полета… бабах! 10 лет и 7 миллиардов долларов, потраченных на разработку. Четыре полуторатонных спутника научной программы Cluster (изучение... // habrahabr.ru
 
 44

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru