Обновление программного обеспечения на миллиарде миль
Может ли кто-то здесь пролить некоторый свет на то, как НАСА разрабатывает архитектуру своего космического корабля, чтобы гарантировать возможность исправления ошибок в развернутом коде?
Я никогда не создавал системы типа "реального времени", и этот вопрос пришел в голову после прочтения этой статьи:
http://pluto.jhuapl.edu/overview/piPerspective.php?page=piPerspective_05_21_2010
"Одной из первых важных вещей, которые мы сделаем, когда мы разбудим космический корабль на следующей неделе, будет загрузка почти 20 мелких исправлений ошибок и других улучшений кода в нашу программу защиты от сбоев (или" ответ автопилота ")".
5 ответов
Я был разработчиком программного обеспечения для систем телефонной коммутации общего пользования, которое имеет довольно серьезные ограничения в отношении надежности, доступности, живучести и производительности, которые приближаются к потребностям космических систем. Я не работал над космическими кораблями (хотя я работал со многими бывшими программистами челноков, когда работал в IBM), и я не знаком с VXworks, операционной системой, используемой на многих космических кораблях (включая марсоходы Mars, которые имеют феноменальный рекорд работы)).
Одним из основных требований к исправляемости является то, что система должна быть спроектирована с нуля для исправления. Это включает в себя структуру модуля, так что можно добавлять новые переменные и заменять методы, не прерывая текущие операции. Это часто означает, что как старый, так и новый код для измененного метода будут резидентными, и операция исправления просто обновляет вектор диспетчеризации для класса или модуля.
Практически обязательно, чтобы программное обеспечение исправления (и удаления исправлений) было интегрировано в операционную систему.
Когда я работал над телефонными системами, мы обычно использовали функции исправления и замены модулей в системе для загрузки и тестирования наших новых функций, а также исправлений ошибок задолго до того, как эти изменения были представлены для сборок. Каждый разработчик должен уметь исправлять и заменять модули как часть своей работы. Он повышает уровень доверия к этим компонентам и обеспечивает регулярное выполнение кода исправления и замены.
Тестирование в этих системах намного строже, чем в любом другом проекте. Полные и частичные макеты системы развертывания будут легко доступны. Вероятно, также будут среды виртуальных машин, где можно будет выполнить и протестировать полную нагрузку. Планы тестирования на всех уровнях выше модульного теста будут написаны и формально проверены, так же как и формальные проверки кода (и они также будут обычными).
Отказоустойчивое проектирование системы, включая разработку программного обеспечения, имеет важное значение. Я не знаю конкретно о системах космических кораблей, но что-то вроде кластеров высокой доступности, вероятно, является стандартным, с добавленной возможностью запуска как синхронизированной, так и несинхронизированной, и возможностью передачи информации между сторонами во время аварийного переключения. Дополнительным преимуществом этой структуры системы является то, что вы можете разделить систему (при необходимости), перезагрузить неактивную сторону новой загрузкой программного обеспечения и протестировать ее в производственной системе, не подключаясь к системной сети или шине. Когда вы убедитесь, что новое программное обеспечение работает правильно, вы можете просто переключиться на него.
Как и в случае с исправлениями, каждый разработчик должен знать, как выполнять отработку отказа, и должен делать это как во время разработки, так и во время тестирования. Кроме того, разработчики должны знать все проблемы с обновлением программного обеспечения, которые могут вызвать аварийное переключение, и должны знать, как писать исправления и заменять модули, чтобы избежать возможных аварийных переключений по возможности.
В целом, эти системы разрабатываются с нуля (аппаратное обеспечение, операционная система, компиляторы и, возможно, язык программирования) для этих сред. Я не считаю Windows, Mac OSX, Linux или любой другой вариант Unix достаточно надежным. Частично это требования реального времени, но вопрос надежности и живучести так же важен.
ОБНОВЛЕНИЕ: Как еще один интересный момент, вот блог одного из водителей Марсохода. Это даст вам представление о повседневной жизни обслуживающего космического корабля. Аккуратные вещи!
Я никогда не создавал системы реального времени, но я подозреваю, что в этих системах у них не будет механизма защиты памяти. Им это не нужно, так как они сами написали все свое программное обеспечение. Без защиты памяти для программы будет тривиально записать место в памяти другой программы, и это можно использовать для оперативного исправления работающей программы (в прошлом написание самоизменяющегося кода было популярной техникой, без защиты памяти). те же самые методы, которые используются для самоизменения кода, могут использоваться для изменения кода другой программы).
Linux может делать небольшие исправления ядра без перезагрузки в течение некоторого времени с Ksplice. Это необходимо для использования в ситуациях, когда любое время простоя может быть катастрофическим. Я никогда не использовал это сам, но я думаю, что техника, которую они используют, в основном такова:
Ksplice может применять патчи к ядру Linux без перезагрузки компьютера. Ksplice принимает в качестве входных данных унифицированный diff и исходный исходный код ядра и обновляет работающее ядро в памяти. Использование Ksplice не требует какой-либо подготовки перед первоначальной загрузкой системы (например, работающее ядро не требует специальной компиляции). Чтобы сгенерировать обновление, Ksplice должен определить, какой код в ядре был изменен патчем исходного кода. Ksplice выполняет этот анализ на уровне объектного кода ELF, а не на уровне исходного кода C.
Чтобы применить исправление, Ksplice сначала останавливает работу компьютера, поэтому это единственная запущенная программа. Система проверяет, что ни один из процессоров не выполнял функции, которые будут изменены патчем. Ksplice изменяет начало измененных функций так, чтобы они вместо этого указывали на новые, обновленные версии этих функций, и изменяет данные и структуры в памяти, которые необходимо изменить. Наконец, Ksplice возобновляет работу каждого процессора, где он остановился.
(из Википедии)
Ну, я уверен, что у них есть тренажеры для тестирования и механизмы для горячей установки исправлений. Взгляните на связанную статью ниже - там довольно хороший обзор дизайна космического корабля. Раздел 5 обсуждает вычислительную технику.
http://www.boulder.swri.edu/pkb/ssr/ssr-fountain.pdf
Отметить:
- Резервные процессоры
- Командное переключение с помощью карты восходящей связи, не требующей помощи процессора
- Запаздывающие правила
Я не работал на космическом корабле, но все машины, на которых я работал, были построены так, чтобы иметь стабильное состояние простоя, при котором можно на короткое время выключить машину для исправления прошивки. Системы, в которых были установлены "живые" обновления, - это те, которые были разбиты на взаимодействующие компоненты, где вы можете отключить один сегмент системы достаточно долго, чтобы обновить его, а другие компоненты могут продолжать работать в обычном режиме, поскольку они допускают временное время простоя. обслуживаемого компонента.
Один из способов сделать это - иметь параллельные (избыточные) возможности, например, параллельные машины, которые выполняют одну и ту же задачу, чтобы процесс можно было направить вокруг обслуживаемой машины. Преимущество этого подхода состоит в том, что вы можете отключить его на более длительные периоды для более значительного обслуживания, такого как регулярное профилактическое обслуживание оборудования. Если у вас есть такая возможность, поддержка времени простоя для прошивки довольно просто.
Одним из подходов, который использовался в прошлом, является использование LISP.