Потеря связи с зондом Deep Impact в 2013 году

12 января 2005 года с мыса Канаверал стартовал зонд Deep Impact, созданный для изучение внутреннего состава кометы 9P/Темпеля. Зонд достиг кометы в июле 2005 года, после чего разделился на импактор и пролетную часть. 4 июля 2005 года 370 килограммовый импактор успешно столкнулся с ядром кометы на скорости около 10.3 км/с, выбросив в космос здоровенное облако пыли:

Согласно измерениям, проведенным космическим аппаратом Stardust в 2011 году, диаметр кратера, образовавшегося в результате столкновения, составил около 150 метров.

По завершению основной миссии, NASA направило зонд Deep Impact к комете 103P/Хартли в рамках расширенной миссии “EPOXI”. Пролет этой кометы состоялся 4 ноября 2010 года:

В конце 2011 года, аппарат был отправлен на перехват астероида (163249) 2002 GT пролет которого должен был состоятся в 2020 году. Однако в августе 2013 года контакт с аппаратом был потерян:

3 сентября 2013:
… Связь с аппаратом утеряна между 11 и 14 августа (связь с аппаратом поддерживается раз в неделю). Последний сеанс связи был проведен 8 августа. Проведенное расследование позволило установить причину неполадки. Дальнейшие усилия направлены на определение лучшего способа восстановить связь с аппаратом.

23 сентября 2013:
… все попытки передачи низкоуровневых аппаратных команд не увенчались успехом. На этом все возможные сценарии восстановления связи с аппаратом были исчерпаны. Мы рекомендовали NASA объявить аппарат утерянным. NASA официально заявило об утере аппарата в четверг 19 сентября.

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

Basically, it was a Y2K problem, where some software didn’t roll over the calendar date correctly… The spacecraft’s fault-protection software (ironically enough) would have misread any date after August 11, 2013, triggering an endless series of computer reboots aboard Deep Impact.

Гораздо более подробное описание нашлось на сайте NASA Lessons Learned. Далее в моем переводе:

Хотя точную причину потери аппарата невозможно установить с полной уверенностью, команда управляющая полетом в Лаборатории реактивного движения вместе с главным разработчиком аппарата обнаружили потенциальную проблему с обработкой временных меток, которая могла привести к потере контроля над ориентацией аппарата. Программное обеспечение зонда включает в себя функцию, которая регистрирует и сохраняет в журнал все события, связанные с обработкой сбоев, такие как обнаружение симптомов, обнаружение сбоев, реагирование на сбой и сброс процессора. Функция вычисляет бортовое время в миллисекундах и сохраняет его как целое число. Для этого, функция берет бортовое время в секундах, представленное как 64 битное число с плавающей запятой, умножает его на 10, и переводит его в 32 битное беззнаковое число. Код, выполняющий преобразование, не защищен от целочисленного переполнения, при котором результат не может быть корректно представлен 32 битным числом. Это произошло когда бортовые часы достигли отметки 429496729.6 секунд, что соответствует 223 дню 2013 года. Начиная с этого момента, выполнение этой функции приводит к ошибке вычисления с плавающей запятой, которая в конечном итоге вызывает сброс процессора.

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

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

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

Далее, в документе упоминаются другие инциденты, вызванные ошибками переполнения:

Подобные ошибки преобразования данных не редки и могут иметь катастрофические последствия. Ракета Arian 5 самоликвидировалась во время первого тестового полета в 1996 году, так как 64 разрядное число с плавающей точкой в системе управления было слишком велико, чтобы быть представлено как 16 разрядное знаковое целое. Неудача при попытке перехвата иракского Скада американской ракетой Патриот привела к гибели 28 американских солдат в 1991 году. Она была вызвана преобразованием времени в ограниченное 24 битное представление. Так как способ обработки временных меток реализованный зондом Deep Impact используется повсеместно, похожие проблемы могут затрагивать базовое программное обеспечение, используемое другими проектами космического назначения. Докладная записка, написанная Michael Sierchio, была разослана 29 другим проектам в Лаборатории реактивного движения, чтобы предупредить о потенциальной уязвимости, скрывающейся в коде системы обработки сбоев.

А вы проверяете свой код на отсутствие проблем с целочисленным переполнением?