Охота на инопланетные баги: почему космические компьютеры непохожи на обычные

Ведущий специалист компании Wind River Systems по операционным системам Майк Делиман не раз вспоминал январь 2004 года, когда он получил срочный вызов из NASA. Его помощь потребовалась для того, чтобы разобраться в происходящем на Марсе.

На Марсе не происходило ничего хорошего. Вскоре после посадки марсоход Spirit прервал связь с центром управления полётами. Создатели аппарата сутками пытались его оживить, но без особого успеха. Он отказывался реагировать на команды с Земли. Данные телеметрии, описывающие его состояние, удалось скачать лишь на третий день, и они были безрадостными. Вместо того, чтобы перейти в режим сна, марсоход интенсивно расходовал заряд батареи. В NASA всерьёз опасались, что Spirit не удастся вернуть в строй.

Именно в этот момент к операции по спасению марсохода подключился Делиман. У него особый опыт в этой области: дело в том, что компания Wind River Systems разрабатывает операционную систему реального времени VxWorks, которую использует бортовой компьютер Spirit, а Делиман лично вносил в неё нужные NASA изменения. Лучше него в этой версии системы не разбирался никто.

Большинство пользователей, скорее всего, никогда не слышали об VxWorks. Эту систему не ставят на обычные компьютеры, однако в той области, где она используется, у неё не так уж много конкурентов. VxWorks предназначена для встраиваемых систем: бортовых компьютеров самолётов и автомобилей, систем управления промышленными роботами, контроллеров медицинского и телекоммуникационного оборудования — одним словом, устройств, ошибки которых обходятся куда дороже обычного.

К тому времени, когда Spirit отправили в космос, VxWorks успела стать главной системой американских межпланетных станций, но что ешё важнее, её использовал марсоход Sojourner, высадившийся на Марсе в 1997 году. Программное обеспечение Spirit и его двойника Opportunity представляло собой усовершенствованную версию софта Sojourner.

Операционные системы реального времени отличаются тем, что их реакция на внешние события предсказуема. Они гарантируют, что любое событие будет обработано в течение обещанного срока — как правило, речь идёт о десятой доле секунды. Не нужно объяснять, почему это качество делает VxWorks и другие системы реального времени предпочтительнее для использования в космических аппаратах, чем Windows или Linux.

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

Взять хотя бы автоматическое управление памятью. Считается, что оно повышает надёжность программ, и это действительно так. Программисты — всего лишь люди, а людям свойственно допускать ошибки. Достаточно забыть освободить выделенную память в неподходящем месте, чтобы программа начала падать. Автоматическая «сборка мусора» исключает подобные ошибки.

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

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

Боевое крещение Curiosity

Новый марсоход Curiosity столкнулся с первыми значительными неполадками в начале марта. По необъявленной пока причине основной бортовой компьютер аппарата вошёл в безопасный режим и отказался продолжать работу. Через пару дней в NASA решили не рисковать и перевели управление Curiosity на запасной бортовой компьютер, точно такой же, как первый, но исправный. Впрочем, проблема в итоге оказалась несерьёзной. Сейчас марсоход по-прежнему использует запасной компьютер, но при необходимости может переключиться обратно.

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

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

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

Использование препроцессора жёстко ограничено. При вычислении выражений необходимо избегать побочных эффектов. Запрещён оператор goto (хотя как раз встраиваемые системы — тот редкий случай, когда он мог бы быть полезен, поскольку с его помощью удобно реализовывать конечные автоматы). Ограничено использование ссылок на функции, зато правильность всех данных без исключения должна проверяться в обязательном порядке.

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

В том злополучном январе, когда сломался Spirit, Майк Делиман и его коллеги из NASA, находящиеся в нескольких часовых поясах, несколько недель круглые сутки не отходили от компьютеров, пытаясь привести марсоход в рабочее состояние. «Я работал без выходных, по три раза вставал ночью, чтобы переговорить с нужными людьми, и прерывался только для того, чтобы перекусить, поспать, сходить в душ и погулять с собаками», — рассказывал Делиман в интервью ACM Queue.

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

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

Как определить, что именно произошло? Осмотреть сломанную машину нельзя, и с измерительными инструментами в неё не залезешь. Программу, которая на нём идёт, не запихнёшь в отладчик, чтобы узнать, в какой момент она отказывается продолжать работу. И даже когда такая возможность есть, экспериментировать с компьютером, который находится на другой планете, — слишком большой риск. В космосе нет команды «Отменить».

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

К рабочей станции Sun в кабинете Делимана была подключена одна из копий бортового компьютера Spirit и Opportunity. Внешне она напоминала потрёпанный чемоданчик, но в действительности стоила дороже любого другого оборудования, находившегося поблизости. Цена одного лишь процессора, использованного в Spirit, составляет 200-300 тысяч долларов. При этом его не назовёшь мощным. Он отставал от уровня 2004 года лет на пятнадцать, если не больше.

В марсоходах стоял 20-мегагерцевый процессор BAE RAD6000, имеющий архитектуру Power PC и напоминающий процессор рабочей станции IBM серии RS/6000, выпускавшейся в начале девяностых. Объём оперативной памяти Spirit и Opportunity составлял по 128 мегабайтов, а в качестве накопителя использовались 256 мегабайтов флэша. Кроме того, имелось трёхмегабайтное ПЗУ.

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

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

Злоключения Galileo на пути к Юпитеру

Несмотря на многочисленные поломки, аппарат добрался до Юпитера и сделал большую часть запланированной работы. А всё потому, что инженеры NASA сумели найти программное решение аппаратных проблем, которые казались непреодолимыми.

Дело в том, что между космическим аппаратом и очередным айфоном такая же разница, как между черепахой и бабочкой-однодневкой. Разработка межпланетного зонда продолжается не один год — и это мягко сказано. К примеру, Galileo, летавший к Юпитеру в конце девяностых, был задуман в середине шестидесятых. Работа над его бортовым компьютером началась в 1976 году — во времена, когда для записи тактовой частоты или объёма ОЗУ персональных компьютеров хватало одной цифры.

Планировалось, что Galileo стартует в 1982 году, но то по одной, то по другой причине его откладывались до 1989 года. Зонду потребовалось шесть лет для того, чтобы приблизиться к цели, а затем он ещё восемь лет передавал данные с Юпитера. На Земле менялись поколения электроники, а бортовой компьютер Galileo оставался неизменным и продолжал работу.

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

Смешно жаловаться на RAD6000 (который, кстати, до сих пор работает на Марсе, хотя прошло десять лет), когда специалистам из NASA до сих пор приходится поддерживать связь с «Вояджерами», запущенными в 1977 году, а спроектированными и того раньше. RAD6000 хотя бы имеет какие-то современные аналоги — скажем, процессор игровой приставки XBox 360. О бортовых компьютерах «Вояджеров» такого не скажешь.

Это гости из забытого времени, столкновение с которыми должно вызывать у современных программистов трепет. На каждом из них стоит по паре крайне маломощных компьютеров трёх совершенно разных типов и назначений, в которых сам чёрт ногу сломит: четыре восемнадцатиразрядных и два шестнадцатиразрядных процессора с тактовой частотой 250 килогерц, причём два из них имеют доступ лишь к ПЗУ объёмом 4096 восемнадцатиразрядных слов, ещё два — к двум банкам ОЗУ ёмкостью 8196 шестнадцатиразрядных слов, а остальные — к двум банкам ОЗУ ёмкостью 4096 восемнадцатиразрядных слов (в сумме набирается около 64 килобайтов).

И этот динозавр не просто продолжает работать уже без малого сорок лет — его по-прежнему приходится программировать, отлаживать и чинить. Это значит, что где-то в закромах американского аэрокосмического агентства содержится небольшой компьютерный парк Юрского периода: работоспособная копия бортовой вычислительной машины «Вояджеров». И кому-то приходится за ним ухаживать, помня и используя методы полувековой давности, на фоне которых все современные ограничения, которые налагают в NASA на программистов, кажутся нелепым баловством.

Один из компьютеров Voyager

Удалённый ремонт понадобился одному из аппаратов относительно недавно: в 2010 году нарушилась связь c Voyager 2. Вместо телеметрии зонд передал с окраины Солнечной системы нечитаемый поток цифрового мусора. Инженеры три недели определяли причину: оказалось, что одна из ячеек памяти вышла из строя и поменяла своё значение на противоположное. Программное обеспечение Voyager 2 пропатчили, чтобы он обходил испорченную область памяти стороной.

И причина неисправности Voyager 2, и способ её исправления некомфортабельно близка к железу. Современные программисты почти никогда не опускаются до уровня отдельных ячеек, регистров и портов. Обычно работа происходит на много уровней абстракции выше, и ошибки почти никогда не имеют отношения к тому, что происходит в реальном мире. В космосе же (да и вообще во встраиваемых применениях) реальный мир трудно игнорировать.

Та проблема марсохода Spirit, над решением которой бился Делиман в 2004 году, вполне могла корениться не в программной, а в аппаратной ошибке, вызванной внешним воздействием. Подумайте сами: действие происходит на другой планете. Spirit стартовал с Земли и пережил существенные нагрузки, а затем совершил автоматическую посадку — и не факт, что достаточно мягкую. Во время старта или посадки он запросто мог получить механические повреждения. После того, как аппарат покинул радиационный пояс Земли, его непрерывно обстреливали заряженные частицы. Шальная частица способна повлиять на работу электроники, а при особом невезении — даже полностью сжечь одну из микросхем. Наконец, бортовой компьютер мог перегреться или пострадать от перепада напряжении.

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

В Spirit и Opportunity имеется плата, которая перезапускает бортовой компьютер, когда он подвисает. Пока компьютер работает исправно, специальный процесс следит, чтобы перезапуска не произошло. Когда он замолкает, плата понимает, что произошёл сбой, и выполняет сброс.

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

Сброс происходил снова и снова. Именно поэтому из Spirit никак не удавалось вытянуть телеметрию или перевести его в спящий режим. После шестидесяти перезагрузок батарея истощилась настолько, что марсоход перешёл в режим сохранения энергии, при котором не требовалась полная реинициализация файловой системы. Это его и спасло. Решение проблемы оказалось совсем простым: лишние файлы удалили, а чтобы история не повторилась, конфигурацию некоторых модулей слегка изменили.

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

Очертания компьютеров, которые мы используем, напрямую связаны с их техническими ограничениями. Главным ограничением персональных компьютеров долгое время была их недостаточная мощность. Когда несколько лет назад начался бурный рост популярности мобильных устройств, ограничения стали совсем другими. Теперь всех волнует не производительность процессора, а энергопотребление и ёмкость батарей. И посмотрите, к чему это привело: мобильные платформы, завоевывавшие мир последние пять лет, устроены совсем иначе, чем операционные системы, которые были распространены на ПК.

Что дальше? Аналитики предсказывают распространение самоуправляемых автомобилей, беспилотных летательных аппаратов и даже мобильных роботов. Их прогнозы, как правило, нужно делить на два, но тем не менее: разработчиков таких устройств будут беспокоиться совсем о других вещах, чем создатели Android или Windows. Надёжность и долголетие станет важнее и производительности, и энергопотребления. Тут-то и пригодятся уроки космоса.

"Компьютерра"