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