Введение XX век стал веком освоения космического пространства (стр. 9 )

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

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

Межзадачное взаимодействие и информационный обмен по шинам передачи данных

Межзадачное взаимодействие организовано с использованием очередей сообщений и семафоров. Архитектурно каждая задача построена с использованием бесконечного цикла ожидания, получения, обработки вновь принятого сообщения. При этом чтение очередного сообщения из очереди является блокирующей операцией – следовательно при отсутствии новых сообщений задача передает управление операционной системе. Задача с более высоким, чем выполняющаяся в текущий момент, приоритетом, получившая очередное сообщение моментально получает управление, тем самым реализует скорейшую обработку события-сообщения. Условно можно изобразить реализацию данной схемы в операционной системе VxWorks[12]:

void A_task()

{

char can_exit=0;

Queue_id = msgQCreate(MAX_MSGS_QUEUED, sizeof(tsMSGT_MESSAGE), MSG_Q_FIFO);

while(can_exit==0)

{

msgLength=msgQReceive(Queue_id,(char*)&Command, sizeof(tsMSGT_MESSAGE), WAIT_FOREVER);

……

}

}

Рис. 2.1 - Схема работы основного цикла задачи

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

Основным механизмом взаимодействия с оборудованием на космическом аппарате является взаимодействие по цифровым шинам передачи данных. На КА «Канопус-В» совместно используются 2 различных шины: CAN и MKO. Шина CAN используется для взаимодействия с блоками авионики. Каждый узел данной сети может быть многоадресным, что позволяет, используя лишь один CAN контроллер на устройстве обрабатывать группы сообщений с разными адресами получателя. Тем самым одно и то же устройство способно работать как несколько логических устройств. ПО БВС поделено на задачи, и каждая задача имеет определенный идентификатор CAN, и при посылке запросов к оборудованию данный идентификатор явно указывается в пакете. При получении обратного пакета, драйвер шины CAN пересылает сообщение в заданную очередь отравителя. Как видно из описания механизма взаимодействия задачи и оборудование авионики работают в общем адресном пространстве CAN, тем самым упрощая процедуру кодирования – ведь нет необходимости использовать разные протоколы для межзадачного и внешнего взаимодействий. Разумеется данный подход обязательно должен быть оптимизирован для передачи внутренних сообщений между задачами, исключающим физическую передачу по шине, используя вместо этого прямую передачу в очередь задачи-получателя. Для реализации данной идеи должен быть реализован сервис, обслуживающий шину CAN и все сопутствующие запросы, тем самым предоставляя единый интерфейс для посылки сообщений между задачами и между оборудованием. Второе немаловажное предназначение данного сервиса – буферизация сообщений для последующей передачи, а также буферизация входящих сообщений и последующая их маршрутизация до получателей. Передача сообщений с целью последующей отправки по шине реализуется при помощи вызова функции с передачей в нее в качестве аргумента указателя на сообщение, инкапсулирующего в себе всю необходимую информацию. При вызове функция запрашивает из пула свободных сообщений очередное свободное сообщение и производит операцию глубокого копирования данных по указателю. Данная операция нужна из-за того что указатель на сообщение ссылается на стек задачи и сообщение может быть удалено раньше чем будет завершен цикл его обработки. Следующей операцией является помещение сообщения в список ожидающих отправки. При наступлении очередного цикла работы с шиной ПО производит отправку сообщений и помечает их как отправленные. В последствии ПО будет проверять статус каждого сообщения и при приходе на него ответа – отсылать его отправителю. При непоступлении ответа от получателя будет произведена повторная попытка отправки после неудачи которой сообщение будет помечено как свободное и возвращено в пул свободных сообщений, а  отправителю будет направлено сообщение о таймауте передачи.

Рис 2.2 - Схема передачи сообщения по шине CAN

Механизм работы по МКО схож с работой по CAN, но МКО является шиной с отличающимся арбитражем. Устройства на МКО могут работать в следующих состояниях: контроллер шины, оконечное устройство и монитор шины. Бортовая вычислительная система является контроллером шины и поэтому должна обеспечивать арбитраж и инициировать передачу данных. Механизмы передачи данных по МКО более строги и требуют тщательного проектирования.

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

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

Живучесть - парирование отказов

При работе космического аппарата на орбите возможно возникновение ряда нештатных ситуаций к которым ПО должно быть готово. Условно все нештатные ситуации можно разделить на две группы:

-аппаратные отказы;

-программные сбои.

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

Ситуация с отказом оборудования требует еще и точной локализации оказавшего узла. Для этого необходимо производить постоянный мониторинг состояния КА и при обнаружении отказа производить работу по его локализации путем перекрестного анализа показаний с приборов в течении определенного времени. Если отказ подтверждается по нескольким прямым или косвенным признакам необходимо произвести действия по автоматическому парированию отказа, а в случае если это не удается  - перевести КА в энергетически безопасный режим до анализа ситуации.

Исключительные ситуации возникают в пользовательских задачах и являются результатом некорректной операции [1]: деление на ноль, невыровненное обращение к памяти, логарифм отрицательного числа, переполнение стека и прочее. Для парирования таких ситуаций и сохранения работоспособности системы предусмотрены механизмы обработки исключительных ситуаций и связанные с ними обработчики исключений. При возникновении исключения вырабатывается аппаратное прерывание, ловушка (trap) и сигнал операционной системы, которые перехватываются обработчиком исключений. Данный обработчик в общем случае определяет какая из задач вызвала исключение и выполняет некоторые действия для парирования каждого конкретного исключения. В ОС VxWorks после окончания работы обработчика исключения, вызвавшая исключение задача остается в приостановленном состоянии. Дальнейшее решение о перезапуске задачи должно осуществляться после анализа причины появления исключительной ситуации.