Технологии живучести КА

[Рысьь]

Актуальная тема после потери Фобос-Грунта и в свете грядущих миссий Роскосмоса на Луну и Марс. Рассматриваются такие вопросы:
1. Программно-аппаратная реализация защищённых от сбоев и ошибок бортовых вычислительно-управляющих комплексов (ВУК).
2. Реализация аварийного режима (safe mode: http://en.wikipedia.org/wiki/Safe_mode_(spacecraft) )
3. Процедуры аварийного восстановления после сбоев.

Техника во многом одинаковая для трёх видов применений:
1. Пилотируемые КА: на борту есть человек, который что-то может починить, но его безопасность выше сохранности корабля;
2. Околоземные и окололунные беспилотные КА: расстояние до земли — ~0.1 св. с, поэтому реагировать на большую часть аварий Земля может быстро;
3. Далёкие орбитальные или пролётные аппараты (АМС): расстояние до земли — световые минуты и часы, поэтому немедленно реагировать на большую часть аварий приходится борту;

Отдельным подклассом выступают близкие (лунные) и далёкие (планетарные и пр.) поверхностные аппараты: потеря ориентации в невесомости им не грозит, зато мобильные могут перевернуться.

Вначале составим список опасностей для космических (не поверхностных) аппаратов. Замечания и дополнения приветствуются:
А. Аппаратные поломки и сбои КА:
А1. Поломка управляющего блока (ВУК);
А2. Поломка управляемого блока;
А3. Поломка датчика (в т.ч. по причине неверного подключения или нетрадиционной ориентации);
А4. Короткое замыкание с полным обесточиванием блока (в т.ч. вследствие тиристорного эффекта);
А5. Потеря части заряда, проседание напряжения;
А6. Потеря подпитки из-за неориентации на Солнце (с сохранением остаточного заряда);
А7. Потеря заряда и Солнца (полное обесточивание борта);
А8. Потеря связи из-за неориентации на Землю;
А9. Потеря газа или жидкости из-за утечки;
Б. Программные поломки и сбои КА:
Б1. Зависание;
Б2. Одиночная перезагрузка;
Б3. Циклическая перезагрузка;
Б4. Ошибка алгоритма (деление на 0, запись в запрещённую память...);
Б5. Потеря памяти данных;
Б6. Потеря памяти прикладных программ;
Б7. Потеря памяти системных программ;
Б8. Потеря времени (сбой бортовых часов);
В. Ошибки и поломки на Земле:
В1. Ошибки операторов (неверные команды или данные);
В2. Сбой аппаратуры связи;
Г. Опасности окр. среды:
Г1. Перегрев;
Г2. Переохлаждение;
Г3. Радиация — накопление дозы;
Г4. Радиация — попадания ЗЧ, одиночные сбои;
Г5. Попадание космической пыли или мусора;
Г6. Нападение пришельцев, изменение орбиты Земли, сбой физических законов (на случай, если, не смотря на все вышеозначенные старания, аппарат всё ещё работает    

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

Отдельный вопрос — бункер. Точно не знаю, как это называется, но идея такая: в КА нужно иметь некую особо защищённую (от всего) область с долговременным автономным питанием, ресурсы которой сохраняются, даже если засбоит, сломается или выключится всё остальное. Внутри находятся:

1. Часы с корректором и регистром сдвига хронологии миссии;
2. Таймеры с возможностью выдачи прерываний;
3. Журнал событий с указанием приоритета и времени для записей;
4. Память для особо важных данных и кода аварийного восстановления;
5. Возможно, простой компьютер для аварийных действий по защите целостности.
6. Возможно, некоторые датчики: температура, радиация, напряжение...

Вопрос про бункер — где такое есть, как зовётся и как устроено?

Другой вопрос — уровень самостоятельности борта при принятии решений: как определяется, что надо делать немедленно, а на что ждать команды с Земли (если есть связь...).

Слово предоставляется товарищам причастным!  

[PIN]

Рысьь пишет:
Отдельный вопрос — бункер. Точно не знаю, как это называется, но идея такая: в
КА нужно иметь некую особо защищённую (от всего) область с долговременным
автономным питанием, ресурсы которой сохраняются, даже если засбоит, сломается
или выключится всё остальное.

Не буду облобщать, но в знакомых мне реализациях БЦВК:
- часы (счетчик) есть в каждом полукомплекте либо только в модуле реконфигурации, либо в нем + процессорном. И там и там с аппаратной защитой от "переворачивания" одного бита, и там и там - сбрасываемые в ноль при обесточивании. Обесточенному аппарату часы не нужны
- предсмертные журналы ПО БЦВК на некоторых аппаратах - в RAM, на некоторых часть копируется 9когда на это остается время...) в EEPROM.
- "простой компьютер" - это техническое решение, использованное на некотрых платформах 80х годов. При критических сбоях (неоднократных) или полном отказе основных процессоров и используемых ими аппаратных ресурсов происходит переход в защитный режим на отдельный огда резервируемой, иногда нет) процессор с минимумом интерфейсов. в основном  на отдельные датчики и устройства управления ориентацией. Все, что его ПО может делать - крутить аппарат панелями к солнцу, давать земле минимально необходимую информацию для диагностики аппарата и доступ к ресурсам БЦВК для диагностики и конфигурации

[PIN]

Рысьь пишет:
Другой вопрос — уровень самостоятельности борта при принятии решений: как
определяется, что надо делать немедленно, а на что ждать команды с Земли (если
есть связь...).

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

[PIN]

Рысьь пишет:
2. Околоземные и окололунные беспилотные КА: расстояние до земли — ~0.1 св. с,
поэтому реагировать на большую часть аварий Земля может быстро;

Это если контак с аппаратом частый. Сейчас немало летает аппаратов на низкой орбите, сеансы (минут по 10 ) с которыми - раз в сутки или даже двое. И чем дальше, тем таких будет больше и связь будет еще менее редкой. Дорого оно...

[Aleks1961]

Можно начать с книги - Handbook of Space Technology и этих двух глав:

4  Subsystems of Spacecraft
9  Management of Space Projects


Ссылка на книгу присутствует на форуме в разделе "Книги...". Считаю очень толково и грамотно расписано о надежности и качестве, о путях их достижения на разных этапах создания КА.

[Рысьь]

Aleks1961 пишет:
книги - Handbook of Space Technology

Спасибо, почитаем.

SOE пишет:
а время использования наземных станций было минимальным.

Странно, сегодня же есть спутники-ретрансляторы, а с земли можно связяться с низкой орбитой за копейки — телефон Иридиум на 1000 км вверх слышно.

SOE пишет:
"простой компьютер" - это техническое решение, использованное на некотрых
платформах 80х годов

А почему это решение перестали применять с тех пор?

SOE пишет:
сбрасываемые в ноль при обесточивании. Обесточенному аппарату часы не нужны

Странно. Думаю, что нужны, когда речь идёт о АМС и проишествиях типа случившегося с SOHO. Вообще, история его реанимации достойна всяческих анналов    Суть сохранения времени и журнала на период провала питания в том, что аппарат может беспорядочно крутиться или внезапно войти в тень, а потом выйти из неё и через некоторое время получить достаточное количество энергии, чтобы что-то зарядить и включить. Тут аварийной логике надо ответить на вопросы: кто я, где я, что последнее я помню, что у меня в баках и батареях, не сломан ли какой-то блок, и в какую сторону Земля? И тогда часы, память полётного задания с временными метками, знание положения планет и прочих тел и бортовой журнал очень помогут в борьбе с амнезией.

SOE пишет:
только в модуле реконфигурации

А этот модуль сам защищён лучше того, что он конфигурирует? Ведь сбой может быть и в нём.

[PIN]

Рысьь пишет:
Странно, сегодня же есть спутники-ретрансляторы, а с земли можно связяться с
низкой орбитой за копейки — телефон Иридиум на 1000 км вверх слышно.

Это еще дороже. Сейчас, по крайней мере.

[PIN]

Рысьь пишет:
А почему это решение перестали применять с тех пор?

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

[PIN]

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

Так тоже бывает. Есть вариант реализации (на одном недавно запущенном аппарате) когда информация о бортовом времени (счетчик + сдвиг его) периодически переписываются в EEPROM.

[PIN]

Рысьь пишет:
А этот модуль сам защищён лучше того, что он конфигурирует? Ведь сбой может быть
и в нём.

Он надежнее, так как:
- модулей реконфигурации 2 и один из них находится (с оговорками) в горячем резерве
- нет ПО, все "прошито" в FPGA и PROM
- они просты, настолько, насколько можно упростить
- они типовые, то есть, кочуют годами с аппарата на аппарат (и даже с платформы на платформу) с минимальными модификациями. Например, где-то нужно мониторить продолжительность открытия клапанов двигателей ДУ, а где-то нет, где-то то нужно отслеживать наличие сигнала "вижу Солнце", а где-то его и быть не может все время.

[PIN]

В случае SOHO, кстати, время вообще ни при чем - в защитном режиме он на отдельном "железном" управлении ориентацией, тени быть не может, ориентация предельно простая - лицом к Солцу, Земля автоматически "в попе". А выживать после стольких эпических ошибок управления не один аппарат не рассчитан...

[Рысьь]

SOE пишет:
типично и использование отдельных (для защитного режима) датчиков системы ориентации.

А зачем отдельных? Они более простые и потому надёжней?

SOE пишет:
где-то нужно мониторить продолжительность открытия клапанов двигателей ДУ, а где-то нет

О, кстати про это! Это как раз реализация пунктов Б1 и Б4. Интересно, как устроена защита от зависаний и перезагрузок при исполнении неразрывных последовательностей операций? Например, изменение орбиты:
1. Включить двигатели ориентации.
2. Подождать N.
3. Выключить двигатели ориентации.
4. Подождать M (идёт поворот).
5. Включить противоположные двигатели ориентации.
6. Подождать N.
7. Выключить противоположные двигатели ориентации.
8. Проверить стабилизацию, вякнуть Земле ТМИ всенаправленной антенной.
9. Включить маршевый двигатель.
10. Подождать X.
11. Выключить маршевый двигатель.
12-19. Повторить пункты 1-8, чтобы вернуться в исходное или в новое положение.

И что будет если в любой момент в ходе таких ответственных операций случится встреча с коварной ТЗЧ? (Особенно, если как раз в этот момент работает двигатль ориентации, либо аппарат вращается по инерции.) Как не стать вторым Фобос-Грунтом?

[PIN]

Рысьь пишет:
А зачем отдельных? Они более простые и потому надёжней?

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

[PIN]

Рысьь пишет:
Интересно, как устроена защита от зависаний и перезагрузок при исполнении
неразрывных последовательностей операций?

Не знаю, не сталкивался с таким лично. Чтобы уменьшить вероятность стать "вторым Фобос-Грунтом" надо стараться планировать миссию и операции по ней так, чтобы операций с единственным шансом не было вообще или они были исключены там, где это хоть как-либо возможно. И создавать адекватный рискам наземный сегмент.
То есть, по моему частному мнению, это история вообще не о БЦВК, его железе и ПО, а об инженерных и организационных решениях системного уровня.

[Ded]

Рысьь пишет:
Актуальная тема после потери Фобос-Грунта и в свете грядущих миссий Роскосмоса на Луну и Марс. Рассматриваются такие вопросы:
1. Программно-аппаратная реализация защищённых от сбоев и ошибок бортовых вычислительно-управляющих комплексов (ВУК).
2. Реализация аварийного режима (safe mode:  http://en.wikipedia.org/wiki/Safe_mode_(spacecraft ) )
3. Процедуры аварийного восстановления после сбоев.

Техника во многом одинаковая для трёх видов применений:
1. Пилотируемые КА: на борту есть человек, который что-то может починить, но его безопасность выше сохранности корабля;
2. Околоземные и окололунные беспилотные КА: расстояние до земли — ~0.1 св. с, поэтому реагировать на большую часть аварий Земля может быстро;
3. Далёкие орбитальные или пролётные аппараты (АМС): расстояние до земли — световые минуты и часы, поэтому немедленно реагировать на большую часть аварий приходится борту;

Отдельным подклассом выступают близкие (лунные) и далёкие (планетарные и пр.) поверхностные аппараты: потеря ориентации в невесомости им не грозит, зато мобильные могут перевернуться.

Вначале составим список опасностей для космических (не поверхностных) аппаратов. Замечания и дополнения приветствуются:
А. Аппаратные поломки и сбои КА:
А1. Поломка управляющего блока (ВУК);
А2. Поломка управляемого блока;
А3. Поломка датчика (в т.ч. по причине неверного подключения или нетрадиционной ориентации);
А4. Короткое замыкание с полным обесточиванием блока (в т.ч. вследствие тиристорного эффекта);
А5. Потеря части заряда, проседание напряжения;
А6. Потеря подпитки из-за неориентации на Солнце (с сохранением остаточного заряда);
А7. Потеря заряда и Солнца (полное обесточивание борта);
А8. Потеря связи из-за неориентации на Землю;
А9. Потеря газа или жидкости из-за утечки;
Б. Программные поломки и сбои КА:
Б1. Зависание;
Б2. Одиночная перезагрузка;
Б3. Циклическая перезагрузка;
Б4. Ошибка алгоритма (деление на 0, запись в запрещённую память...);
Б5. Потеря памяти данных;
Б6. Потеря памяти прикладных программ;
Б7. Потеря памяти системных программ;
Б8. Потеря времени (сбой бортовых часов);
В. Ошибки и поломки на Земле:
В1. Ошибки операторов (неверные команды или данные);
В2. Сбой аппаратуры связи;
Г. Опасности окр. среды:
Г1. Перегрев;
Г2. Переохлаждение;
Г3. Радиация — накопление дозы;
Г4. Радиация — попадания ЗЧ, одиночные сбои;
Г5. Попадание космической пыли или мусора;
Г6. Нападение пришельцев, изменение орбиты Земли, сбой физических законов (на случай, если, не смотря на все вышеозначенные старания, аппарат всё ещё работает    

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

Отдельный вопрос — бункер. Точно не знаю, как это называется, но идея такая: в КА нужно иметь некую особо защищённую (от всего) область с долговременным автономным питанием, ресурсы которой сохраняются, даже если засбоит, сломается или выключится всё остальное. Внутри находятся:

1. Часы с корректором и регистром сдвига хронологии миссии;
2. Таймеры с возможностью выдачи прерываний;
3. Журнал событий с указанием приоритета и времени для записей;
4. Память для особо важных данных и кода аварийного восстановления;
5. Возможно, простой компьютер для аварийных действий по защите целостности.
6. Возможно, некоторые датчики: температура, радиация, напряжение...

Вопрос про бункер — где такое есть, как зовётся и как устроено?

Другой вопрос — уровень самостоятельности борта при принятии решений: как определяется, что надо делать немедленно, а на что ждать команды с Земли (если есть связь...).

Слово предоставляется товарищам причастным!

Это Вы "мощно задвинули".
Что конкретно хотите узнать или обсудить? А то все в кучу.

[Ded]

Рысьь пишет:
Странно, сегодня же есть спутники-ретрансляторы, а с земли можно связяться с низкой орбитой за копейки — телефон Иридиум на 1000 км вверх слышно

Подумайте еще раз...

[Рысьь]

ОК, тогда давайте по конкретным случаям. Вот в прошлом году Протон навернулся из-за неверно установленных ДУСов. Могла ли БЦВМ как-то парировать эту ошибку? (Это пункт Б3.) Помнится, однажды посла запуска какого-то из Глонассов обнаружился переворот одного из тамошних датчиков ориентации. Однако аппарат не потерялся и как-то смог связаться с Землёй; проблему починили перепрошивкой.

А как насчёт защиты от тиристора передёргиванием питания с потерей памяти? Отменить это нелья, т.к. иначе защищаемый блок сгорит. Но что, если тиристор случился в БЦВМ при исполнении важных расчётов или при активных манёврах на орбите?

А если речь не о тиристоре, а о невосстановимой ошибке в памяти, которую Хэмминг не исправил? Такая ошибка произошла на зонде New Horizons, летящем к Плутону: http://www.plutotoday.com/news/viewpr.html?pid=22225 .

Ded пишет:
Подумайте еще раз

Подумал. Не помогло. Что не так с Иридиумом и ретрансляторами?

[PIN]

Рысьь пишет:
А если речь не о тиристоре, а о невосстановимой ошибке в памяти, которую Хэмминг не исправил? Такая ошибка произошла на зонде New Horizons, летящем к Плутону:

...то происходит всего лишь перезагрузка БЦВМ. Переключения состояния в других местах, как-то: блоке выдачи разовых команд (с выдачей разовой команды без всяких на то видимых причин), неожиданные включения/выключения потребителей в блоке электро-распределения) приводят иногда к куда более интересным последствиям. Но тоже никак не катастрофическим если аппарат грамотно спроектирован.

Далеко не каждый аппарат после перезагрузки такой (как new Horisons) переходит в защитный режим.

[PIN]

Рысьь пишет:
Протон навернулся из-за неверно установленных ДУСов. Могла ли БЦВМ как-то парировать эту ошибку? (Это пункт Б3.)

Я полагал, тема о КА...

[Рысьь]

SOE написал:
Я полагал, тема о КА

Не только, алгоритмы же похожие. В космосе тоже может навернуться датчик ориантации — и что тогда?

Далеко не каждый аппарат после перезагрузки такой (как new Horisons) переходит в защитный режим

Там дело хитрее; у них 2 компа (как я понял, одинаковых): 1-й управляет и обсчитывает ПН (т.е. научные приборы), а 2-й — обслуживающие системы. Работать они могут одновременно и независимо перегружаться. Причина решения ясна, но настолько такой подход распространён?

происходит всего лишь перезагрузка БЦВМ

Да, но что будет, если в этот момент идут активные манёвры или (хуже того) влёт в атмосферу? Там лишня секунда без правильной реакции может стоить жизни аппарату. Кроме того, сама по себе перезагрузка это половина дела — надо ещё как-то исправить ошибку. Если это код, то переписать его из архива (если он есть) или запросить с Земли (но надо иметь связь и ждать). Если данные, то надо смотреть — какие; можно ли просто удалить, можно ли пересчитать или надо грузить с Земли. Как эти алгоритмы устроены? И что будет, если ошибка обнаружится в самом этом алгоритме (коде или данных)?

в блоке выдачи разовых команд (с выдачей разовой команды без всяких на то видимых причин), неожиданные включения/выключения потребителей в блоке электро-распределения) приводят иногда к куда более интересным последствиям

Первое чинится временнЫм дублиированием или подтверждением выданных команд. Или после выдачи команды надо вставить некий проверочный хэш. Или добавить «соль» (salt, это понятие из криптографии: удлинняющая добавка к паролю или шифруемому тексту).

Второе (помимо вышесказанного) определяется датчиками тока и проверкой активности потребителей. Точнее, это всё намётки в режиме «если б главным конструктором был я»