Написание кода для космических аппаратов


 

Нейл: Ваша основная задача в проекте MER заключалась в портировании VxWorks на процессор Rad6000, верно? Работали ли вы также над приложениями для MER? Какие были типичные обращения за поддержкой? Не могли бы Вы привести пример такого обращения из НАСА на этом этапе?

Делиман: Моя основная задача заключалась в обновлении и поддержке программного обеспечения и расширении его, как того требовала команда MER. В январе, когда марсоход Спирит испытывал проблемы с файловой системой, меня вызвали, чтобы помочь диагностировать проблему, а, так как мы лучше в этом разбирались, то и помочь охарактиризовать ее точный тип и масшабы. Если на пальцах, то у нас было два набора блоков памяти для хранения данных: очень большой объем памяти для долгосрочного хранения (flash память) и набор небольших участков в оперативной памяти для временного хранения (они использовались для кеширования данных, пока те не будут перенесены на flash-память). ПО, которое управляло маленькими блоками памяти могло запросить дополнительные блоки при необходимости; в конечном итоге, в системе попросту закончилась доступная память и весь процесс, управляющий блоками памяти аварийно завершился. В результате проявился ряд других проблем, которые и привели к череде перезагрузок системы.

Нейл: Чем осложняется написание кода для космических аппаратов?

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

Нейл: Насколько отличается отладка ошибок на земле и в космосе?

Делиман: На земле Вы используете все, что есть под рукой, включая отладочные инструменты (WinView, дампы памяти, отладчики, работающие с исходным текстом и т.д.) Находясь на разных планетах, приходится в основном думать о проблеме и запускать тесты на том, что есть в лаборатории, чтобы посмотреть, удастся ли воспроизвести симптомы.

Нейл: Можете ли Вы привести пример проблемы, с которой пришлось столкнуться в проекте MER? Как Вы исправили проблему — загрузили исправление или целиком новую версию опреационной системы или приложений?

Делиман: В случае со сбоем файловой системы на Спирите (управление памятью), команда из лаборатории реактивных двигателей еще до инцидента поняла, что здесь может возникнуть проблема. Они приняли наилучшее решение из возможных, отправив на марсоход подпрограммы, для удаления старых файлов, освобождая тем самым место как в долговоременном хранилище, так и в наборе маленьких блоков. Но на следующий день, команда обнаружила, что не все подпрограммы отработали как следует. Их должны были обновить в День 19 (19-й день нахождения на Марсе). К сожалению, в День 18, случилась эта неполадка.

Первое что мы сделали, это диагностировали и классифицировали эту проблему насколько это было возможно, затем протестировали способы ее воспроизведение и предотвращения. Мы обнаружили, что некоторые условия тестирования в лаборатории не соответствовали в точности тому, что происходило на Марсе. Команда создала набор изменений, на основе различий между лабораторией и условиями на Марсе и теми наработками, которые мы сделали для предотвращения такой ситуации в будущем, а затем послали их на оба марсохода (Спирит и Оппотьюнити). Эти изменения касались, в основном, приложений. Надо сказать, что проблема частично заключалась в неправильной настройке — система чрезвычайно сложная и есть масса компонентов, которые необходимо настраивать, чтобы они правильно работали в специфических случаях. Все настраиваемые компоненты работали в точности так, как они были настроены.

Нейл: Как различия в космическом аппаратном обеспечении влияют на то, что программы "видят" или делают?

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

Нейл: Похожа ли защита космического корабля от воздействия окружающей среды на защиту процессора или здесь есть различия?

Делиман: Защитить космический корабль намного проще, чем процессор. Защита процессора может длиться годами и потребует неоднократного тестирования и переделывания, прежде чем удастся получить процессор, который будет одновременно устойчив к радиации и функционален. Это дорогостоящий и длительный процесс. Этим объясняется, почему процессоры, предназначенные для работы в космосе, отстают по своим характеристикам от обычных процессоров. Например, современный "космический" процессор — это чип на основе PPC750, который работает на частоте 130 MHz, тогда как обыкновенный PPC750, работает на частоте более 1 GHz.

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

Нейл: Какие типы программного обеспечения являются ключевыми для операционной системы на космическом корабле?

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

Нейл: Как происходило программирование для космического корабля?

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

Следующая глава: "Жесткие ограничения".

Реклама
Запись опубликована в рубрике космос. Добавьте в закладки постоянную ссылку.

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s