Пару месяцев назад на edx.org завершился курс «Введение в аэрокосмическую технику: космонавтика и пилотируемые космические полеты».
Курс вел американский астронавт, в настоящее время профессор Массачусетского технологического института Джеффри Алан Хоффман.
Как следует из названия, курс довольно простой и общий, однако мне он показался весьма интересным и познавательным.
Одна часть курса посвящена вопросу безопасности, и среди прочего мы говорим о безопасности программного обеспечения.
Профессор Хофман приводит интересные примеры проблем с программным обеспечением для авиации и космонавтики.
В этой статье я немного подробнее рассмотрю космические примеры из лекций Гофмана.
Полярный посадочный модуль Марса
Mars Polar Lander (MPL) — космический корабль массой 290 кг, запущенный НАСА 3 января 1999 года для изучения почвы и климата вокруг южного полюса Марса.3 декабря 1999 года при приземлении центру управления не удалось возобновить связь с аппаратом.
MPL в лаборатории НАСА
С развернутыми посадочными опорами и солнечными батареями МПЛ имела высоту 1,06 м и поперечный размер 3,6 м.
Кузов представлял собой сотовую алюминиевую конструкцию, скрепленную графитово-эпоксидными панелями.
При приземлении три алюминиевые опоры раскладываются из транспортного положения и поглощают энергию приземления с помощью разрушаемых алюминиевых вставок, выполненных в виде сот.
Планируемый ход посадки
MPL входит в атмосферу Марса на высоте более 100 км со скоростью ~7 км/с.За 3 минуты аппарат опускается на высоту 8,8 км и замедляется до скорости 0,5 км/с, после чего подает сигнал на раскрытие парашюта, следующий сразу после отделения теплового экрана.
При снижении скорости корабля до 85 м/с с помощью парашюта начинает работать радар, который отслеживает особенности поверхности для определения возможного места приземления.
Схема этапа полета MPL
Через 1 минуту после раскрытия парашюта на высоте 1,3 км, при скорости снижения 80 м/с, спускаемый аппарат отделяется от внешнего корпуса с парашютом (обечайкой) и начинает посадку на торможении двигателей.
Ожидаемое время спуска при работающих двигателях составляет примерно 1 минуту, за это время аппарат опускается на высоту 12 м.
Затем двигатели отключаются, и аппарат совершает плановое падение на поверхность.
Через 5 минут после касания поверхности аппарат начинает разворачивать солнечные панели и ориентировать антенну, что позволит установить связь с Землей.
Затем начинается передача данных, сигнализирующая об успешном приземлении.
Ход событий
3 декабря спускаемый модуль отстыковался от маршевого этапа и перешел в плановый режим радиомолчания до завершения посадки.В 20:04:00 UTC, за 6 минут до входа в атмосферу, программная работа двигателей скорректировала положение аппарата, ориентирующего тепловой экран.
MPL вошла в атмосферу Марса на скорости 6,9 км/с в 20:10:00 UTC. Возобновление связи ожидалось в 20:39:00 UTC после приземления.
Но связь так и не была установлена, а устройство было признано утерянным.
Точная причина потери связи неизвестна, но в отчете о расследовании происшествия сделан вывод, что наиболее вероятной причиной катастрофы стала ошибка программного обеспечения, неправильно засчитывавшего вибрации при развертывании ног как вибрации при приземлении.
В результате аппарат отключил тормозные двигатели на высоте 40 м, несмотря на то, что было известно, что открытие опор могло привести к ложным срабатываниям сигнализации.
Техническими спецификациями на программное обеспечение такой случай не предусмотрен.
Цитата из отчета: «Магнитные датчики, установленные на каждой из трёх посадочных опор, используются для определения момента касания земли и выключения посадочных двигателей.
Данные, полученные в результате нескольких испытаний, показали, что ложные срабатывания датчиков приземления (датчиков Холла) происходят во время раскрытия ног (в этот момент аппарат опускается на парашюте).
Логика программы принимает данные от датчиков в качестве сигнала на посадку, если тревога возникает в двух последовательных показаниях.
Испытания показали, что кратковременные сигналы, генерируемые при развертывании опор, на самом деле достаточно продолжительны, чтобы вызвать ложную тревогу.
Почти всегда одна из трех опор подавала ложный сигнал, который программа принимала за сигнал о приземлении.
Программное обеспечение, которое должно было игнорировать сигналы датчиков до включения алгоритма обнаружения касания земли, было организовано неправильно, и в системе накапливались ложные срабатывания.
Как только на высоте 40 м включался алгоритм обнаружения касания земли, программа сразу же выдавала команду на выключение посадочных двигателей.
На высоте 40 м скорость снижения корабля составляла примерно 13 м/с (47 км/ч), которая без тяги тормозных двигателей под действием гравитации Марса увеличивалась до 22 м/с (80 км/ч).
км/ч) у поверхности расчетная скорость спуска составила 2,4 м/с (9 км/ч).
При такой скорости столкновения с поверхностью аппарат не смог бы выжить».
Если вы посмотрите на алгоритм программы, то заметите, что одна строка сброса состояния переменной IndicatorState к исходному FALSE могла бы спасти устройство, которое обошлось НАСА в 328 миллионов долларов.
Схема алгоритма работы программного обеспечения 
Ариан 5
4 июня 1996 года состоялся первый запуск новой ракеты-носителя «Ариан-5», разработанной Европейским космическим агентством (ЕКА).Запуск закончился неудачей – ракета разрушилась на 39-й секунде полета из-за некорректной работы бортового программного обеспечения.
Запуск первого Ariane 5
Ariane 5 — европейская ракета-носитель семейства Ariane. Запуски осуществляются с космодрома Куру во Французской Гвиане.
На разработку Ariane 5 ушло 10 лет, ее стоимость составила 7 миллиардов долларов, и она предназначалась для замены ракеты-носителя Ariane 4. Запущенная в 1996 году ракета-носитель массой 720 тонн должна была вывести на орбиту четыре спутника массой по 1,2 тонны каждый.
Вращаясь каждый по своей орбите, эти спутники образуют тетраэдр и работают в группе; это был проект «Европейский кластер» по изучению магнитного поля Земли (позже в 2000 году двумя ракетами-носителями «Союз» были успешно выведены на орбиту четыре новых спутника программы «Кластер-II»).
.
Ход событий
Прежде чем описывать инцидент, следует отметить, что конструкция навигационной системы (Инерциальная система отсчета - SRI) у Ariane 5 практически идентична таковой у Ariane 4, в частности, что касается программного обеспечения.Обозначим момент старта как H0. Операции, предшествовавшие пуску, проходили в штатном режиме до момента Н0 – 7 минут, когда было зафиксировано нарушение «критерия видимости».
Поэтому старт был отложен на час.
В H0=12:33:59 UTC был осуществлен запуск, который происходил нормально до момента H0+37 сек.
В следующие секунды ракета резко отклонилась от намеченной траектории, после чего последовал взрыв.
Момент взрыва Ariane 5 во время первого запуска
Итак: на данный момент H0+39 сек.
После запуска из-за высокой аэродинамической нагрузки из-за превышения «угла атаки» критического значения стартовые ускорители ракеты отделились от ее основной ступени, что послужило основанием для включения автодетонационной системы ракеты.
Изменение угла атаки произошло из-за аномального вращения сопел твердотопливного ускорителя; такое отклонение сопел-ускорителя было вызвано командой бортового компьютера на основе информации навигационной системы НИИ 2. Часть этой информации на тот момент была неверной: то, что интерпретировалось как полетные данные, на самом деле являлось диагностической информацией встроенного компьютера системы SRI 2. Встроенный компьютер SRI 2 передал неверные данные, поскольку диагностировал нештатную ситуацию, «переловив» исключение, выданное одним из программных модулей.
В этом случае бортовой компьютер не смог переключиться на резервную систему SRI 1, так как она уже перестала функционировать в течение предыдущего цикла (период 72 мс) по той же причине, что и SRI 2. Исключение, выданное одним из программных модулей SRI, возникло в результате преобразования 64-битного формата с плавающей запятой в 16-битное целое число со знаком, что привело к «ошибке операнда».
Ошибка произошла в программном компоненте, предназначенном исключительно для «настройки» бортовой инерциальной платформы.
Причём, как это ни парадоксально звучит, но значимые результаты данный программный модуль дает лишь до момента отрыва ракеты от стартовой площадки.
После взлета ракеты этот модуль не оказывает никакого влияния на полет. Но функция регулировки в соответствии с установленными к ней требованиями должна действовать еще 50 секунд. после запуска «режима полета».
Эта последовательность основана на требованиях для Ariane 4, но не является обязательной для Ariane 5. Произошла «Ошибка операнда» из-за неожиданно большого значения BH (горизонтального смещения).
Значение BH оказалось намного больше ожидаемого, поскольку траектория полета Ariane 5 существенно отличалась от траектории полета Ariane 4. Последним действием, имевшим фатальные последствия, стало прекращение работы встроенного SPI-компьютера - соответственно, вся навигационная система перестала функционировать.
Возобновить его действия оказалось технически невозможно.
Вся эта цепочка событий была полностью воспроизведена с помощью компьютерного моделирования.
Результаты моделирования, а также материалы других исследований и экспериментов позволили экспертам сделать вывод, что причины и обстоятельства катастрофы полностью выявлены.
Ariane 5 на стартовой площадке перед успешным запуском, Французская Гвиана, 2002 г.
В программном обеспечении Ariane 5 можно найти несколько вариантов устранения досадной ошибки (эти варианты отражены в результатах расследования), но так или иначе эта строчка кода обошлась ЕКА в $500 млн (стоимость загруженной ракеты).
.
Хотелось бы также отметить, что нигде в отчетах не делается акцент на беспомощность резервной системы «Ариана-5» в данном инциденте, хотя в лекциях профессора Хоффмана эта авария упоминается именно в этом контексте.
Имея две идентичные резервные системы, SRI 1 и SRI 2, мы, возможно, сможем защитить себя от физической аппаратной проблемы в одной из систем, но когда дело доходит до программной ошибки, такое дублирование просто бесполезно.
Далее Хоффман говорит о следующем шаге: дублировать программное обеспечение, сделать его другим (разные компании, разные программисты).
Казалось бы, такой структурой мы защитили себя от ошибок, но подобные меры усложняют всю систему и создают еще больше мест, где могут возникнуть ошибки, и в качестве примера приведен третий случай.
Космический шатл
12 апреля 1981 года многоразовый космический корабль «Колумбия» совершил первый испытательный полет с космодрома мыса Канаверал по программе «Спейс Шаттл».
Подготовка к миссии STS-1 - первому полету космического корабля "Шаттл"
Ход событий
10 апреля 1981 года, примерно за 20 минут до запланированного старта, астронавты и обслуживающий персонал шаттла попытались запустить резервную систему управления полетом, дублирующую основную четырехкомпьютерную систему, но не смогли.Запуск был отменен за 16 минут до расчетного времени и перенесен на два дня.
Как тут не вспомнить пресловутый комикс? 
Так получилось, что резервная система управления полетом BFS (Backup Flight Control System) на пятом бортовом компьютере не смогла синхронизироваться с основной системой управления полетом PASS (Primary Avionics Software System), которая уже работала на четырех других бортовых компьютерах.
компьютеры.
В программном обеспечении была ошибка - очень маленькая, почти невероятная, очень запутанная и очень старая ошибка при инициализации PASS. Чтобы сделать шаттл надежным, все дублируется: датчики, электроника, система управления, компьютеры, программное обеспечение, шины данных, источники питания.
Фактически, чтобы удовлетворить концепцию «отказ – работоспособен, отказ – безопасен» «FO/FS» (Fail – Operational, Fail – Safe), многие компоненты дублировались 4 раза: либо буквально (по 4 комплекта оборудования в каждом), , или эквивалентно (чередующиеся схемы, заменяющие один или несколько блоков из необходимых четырех).
Число четыре было выбрано по логической и интуитивной причине: принцип FO/FS требует, чтобы оборудование оставалось полностью работоспособным после первого отказа и обеспечивало безопасный возврат после второго отказа.
Минимальное требование для голосования — три голоса, поэтому на начальном этапе вам необходимо иметь 4 голоса, чтобы иметь возможность проголосовать после одного отказа.
Шаттл имел пять бортовых компьютеров, четыре из них имели одинаковое программное обеспечение и работали на всех ответственных этапах полета.
Такой подход идеален, когда возникают проблемы с компьютерами или другим оборудованием (согласно расчетам, ошибки в системе из трех компьютеров приводили к потере устройства в трех случаях на миллион, а система из четырех компьютеров снижала этот шанс до четырех из миллиона).
миллиардов), но это не подходит. если принять во внимание возможность критической, фатальной ошибки в программном обеспечении.
Таким образом, появилась идея альтернативного ПО на пятом компьютере, которое бы выполняло минимальный функционал ПО на первых четырёх.
Разработка программного обеспечения для BFS включала те же спецификации, тот же язык программирования, тот же компилятор и то же оборудование, на котором было установлено программное обеспечение.
Но он был разработан совершенно другой организацией (Rockwell International для BFS и IBM, Federal Systems Division для PASS) и установлен на разных операционных системах.
ОС для PASS была асинхронной и управляемой по приоритетам — таким образом, самая важная задача всегда сразу же передается под контроль компьютера.
BFS, с другой стороны, больше похожа на полностью синхронную систему «временных интервалов», где каждому процессу дается отведенное время для завершения своего цикла.
К сожалению, синхронные и асинхронные системы плохо сочетаются.
Чтобы BFS могла синхронизироваться с PASS, PASS должен стать синхронным или эмулировать его для синхронизируемых процессов.
Процесс эмуляции был обеспечен с минимальными потерями при разработке.
Как только самый первый компьютер включился и запустил PASS, он попытался синхронизировать запуск всех процессов с данными телеметрии корабля.
Эта синхронизация осуществлялась путем считывания значения времени из данных телеметрии и расчета фаз телеметрии в соответствии с центральным временем.
Утром в пятницу, 10 апреля, стало ясно, что некоторые процессы в PASS обрабатываются не по фазе: на один цикл раньше, чем остальные процессы PASS и BFS. Предполагая, что к нему поступают «зараженные» данные, BFS, как и требовалось, полностью перестала «слушать» информацию от PASS и, следовательно, не смогла синхронизироваться с PASS. Для BFS данные, поступающие за такт, раньше были просто нерасчетными «помехами».
Уже в начале полудня, собрав всех экспертов, НАСА смогло прояснить суть проблемы.
Ошибку в фазировке можно было исправить дедовским методом: если что-то не работает, выключить и снова включить.
Но этот подход не работает для полностью заправленного и готового к запуску космического корабля — бортовые компьютеры играют решающую роль в обработке информации, поступающей от и к системе подготовки к запуску на космодроме.
Доказательства, собранные экспертами, и тот факт, что перезапуск бортовых компьютеров в пятницу вечером устранил проблему, дали представителям НАСА достаточно информации, чтобы запланировать запуск на утро воскресенья.
Но истинные причины ошибки выявились вечером в воскресенье, через 8 часов после запуска.
Бортовые компьютеры используют в качестве часов очередь таймеров операционной системы, первая запись — это желаемое время запуска следующего процесса, когда в любую секунду выполняются сотни процессов, первая запись всегда показывает достаточно точное текущее время (всегда немного тороплюсь, но всегда довольно точен).
Результирующее время всегда одинаково для всех резервных бортовых компьютеров.
При самом первом запуске компьютера активных вычислений нет, это единственный момент, когда очередь пуста.
А поскольку других работающих компьютеров нет, первому разрешили использовать свои часы для определения времени.
Но строка не оказалась пустой, как ожидалось.
За два года до запуска произошло изменение процедуры инициализации шины данных, которая выполнялась до расчета времени запуска.
Эта подпрограмма вставляет значение задержки в очередь таймера.
Это изменение осталось незамеченным: ведь как инициализация шины связана с определением фазы для телеметрии.
Более того, эта временная задержка была достаточно мала, чтобы первая запись в очереди была близка к настоящему времени.
Но через год (за год до запуска) было внесено еще одно изменение, исправляющее возможную перегрузку процессора, немного увеличена задержка.
И этого было достаточно, чтобы существовала вероятность 1/67, что при первом включении бортового компьютера он в своих расчетах времени старта, используя немного опережающее время очереди таймеров, сможет получить результат, когда время начала было в прошлом.
Тогда операционная система задержала начало процесса на один цикл (как это происходит с будильником, когда он установлен на «прошлое», он пропускает 12-часовой цикл, чтобы прозвенеть в «будущем»), что в конечном итоге привело к тому, что почти все процессы выполнялись на один такт с опозданием.
Тестирование могло обнаружить эту ошибку, но возможность ошибки появлялась только на поздних этапах тестирования, когда проверялась вся система, и даже тогда большинство тестов не требовало инициализации с нуля.
И даже в испытаниях, где это требовалось, нужна была лаборатория с достаточно точными моделями PASS, BFS и телеметрии.
И даже если бы все вышеперечисленные условия были соблюдены, при возникновении ошибки возникал соблазн все перезапустить и.
никогда не повторять ошибку и никогда не быть уверенным, не проблема ли это в лабораторной установке.
Вероятно, именно это и произошло в одной из лабораторий НАСА примерно за 4 месяца до полета.
И все же в день включения первого бортового компьютера, за 30 часов до запланированного запуска, проблема дала о себе знать.
Вся информация об ошибке на шаттле была взята из статьи Джона Гармана (заместителя руководителя отдела космического программного обеспечения НАСА).
В нем он также пишет: «Идеальная надежность не обеспечивается, потому что в проектах всегда приходится торговаться по срокам и стоимости.
Поддержание систем программного обеспечения на месте, накопление крупных изменений и дополнений на этапах разработки, а также перенастройка программного обеспечения для соответствия транспортным средствам или миссиям, которые никогда не являются полностью идентичными, — вот проблемы, с которыми мы сталкиваемся сегодня.
Легко сказать: «Не нарушайте правила».
Это невозможно без инвертирования относительного положения программного обеспечения во встроенных системах – и это неправильно! Программное обеспечение может быть «душой» самых сложных систем, но оно по-прежнему является лишь частью поддерживающей оболочки,… очень гибкой частью».
Шаттл приземляется на поверхность озера Роджерс Драй.
Стоимость этой ошибки в программном обеспечении составляет 0$ (конечно, затраты на перенос запуска, вероятно, были немалыми, но в свете рассмотренных ранее аварий, когда произошла полная гибель космического корабля до завершения запланированной миссии, я пренебрегу затратами на переподготовку запуска, тем более что подходящих данных мне найти не удалось).
Но хотелось бы отметить, что эта ошибка задержала сроки запуска на два дня: с 10 на 12 апреля, и, на мой взгляд, нельзя было выбрать более удачную дату для первого запуска шаттла, поскольку на В этот же день, ровно 20 лет назад, Юрий Гагарин совершил полет в космос.
Как тут не вспомнить слова одной черепахи о том, что «случайности не случайны».
Ссылки www.youtube.com/watchЭv=Sc0emcwdyyA www.youtube.com/watchЭv=21o7IZhSvFs en.wikipedia.org/wiki/Mars_Polar_Lander ru.wikipedia.org/wiki/Ariane_5 ru.wikipedia.org/wiki/СТС-1 sunnyday.mit.edu/accidents/mpl_report_4.pdf nssdc.gsfc.nasa.gov/nmc/spacecraftDisplay.doЭid=1999-001A www.osp.ru/os/1998/06/179592 klabs.org/DEI/Processor/shuttle/garman_bug_81.pdf Теги: #Научно-популярные #Космонавтика #ошибки #программное обеспечение #аварии
-
Сети 5G: Что Это Такое?
19 Oct, 24 -
Порекомендуйте Jabber-Сервер
19 Oct, 24 -
Как Нам Дали Задание Сравнить Ежа Со Змеей
19 Oct, 24 -
7 Мифов О Linq To Database
19 Oct, 24
