Диссертация (Динамическое проектирование системы управления движением и навигации малых космических аппаратов дистанционного зондирования Земли с аппаратурой кадровой съемки), страница 6

Для этого в основной код оригинального ядра вносится рядизменений, преобразующих Linux в систему реального времени. Имеетсяготовая программа реального времени, обеспечивающий преобразование«ванильного» ядра Linux в ядро реального времени.33Патч реального времени для системы ОС Linux, называемыйCONFIG_PREEMPT_RT является свободным программным обеспечением соткрытым исходным кодом. Он разрабатывается небольшой группойпрограммистов ядра Linux. Этот патч одобрен основным разработчиком ОСLinux Линусом Торвальдсом и распространяется вместе с оригинальнымядром ОС Linux [36].ПатчCONFIG_PREEMPT_RTминимизируетколичествоневытесняемых участков кода ядра Linux, обеспечивая тем самымвытесняемость процессов ядра Linux прикладными задачами с приоритетомреального времени. Таким образом обеспечиваются требования системыжёсткого реального времени.ПатчCONFIG_PREEMPT_RTнепредоставляеткаких-либодополнительных программных интерфейсов для прикладных программ (API).Всеприложенияреальноговременииспользуютстандартныйинструментарий API Linux, в том числе и для обработки событий в реальномвремени.

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

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

Таким образом, для каждойверсии «ванильного» ядра Linux имеется соответствующая версия патчареального времени.34После того как патч реального времени применён к исходным кодам«ванильного» ядра ОС Linux, формируется набор исходных кодов ОС Linux,удовлетворяющей требованиям ОС жёсткого реального времени. Далееисходный код ядра дополняется исходными кодами драйверов платформы,после чего выполняется компиляция (сборка) обновлённого ядра Linux.

Врезультате такой сборки получается двоичный файл, образ ядра Linux. Этотфайл размещается во внутренней flash-памяти платформы. После запускасистемы данный файл загружается в ОЗУ, управление передаётся в точкувхода и запускается собранная ОС Linux, система жёсткого реальноговремени.Все бортовые программные модули (задачи) функционируют подуправлением ОС Linux. Данная ОС предоставляет ряд механизмовмежзадачного взаимодействия: сигналы, сокеты, очередь сообщений, каналы,семафоры, разделяемая память, файлы и проч.

Из всего многообразиявозможностей выбран лишь один механизм межзадачного взаимодействия –взаимодействие на основе передачи UDP-пакетов. Данный механизм основанна использовании сокетов Linux.Задачи БПО должны иметь возможность передавать данные от однойзадачи к другой, асинхронно оповещать друг друга о произошедшемсобытии. Также необходимо иметь возможность обеспечить синхронизациюработы двух задач во времени. Все эти операции могут быть выполнены сиспользованием механизма передачи UDP-пакетов.Механизм межзадачного взаимодействия на основе UDP-пакетоввыбран по следующим причинам.1) Указанныймеханизмнеявляетсявнутренниммеханизмомопределённой ОС.

Это стандартный механизм обмена данными в сетиInternet. Фактически задачи, использующие при взаимодействии этотмеханизм, ведут себя как узлы сети Internet, обменивающиесяданными.2) Указанный механизм удовлетворяет всем потребностям в межзадачном35взаимодействии,нетнеобходимостииспользованиякаких-либодополнительных механизмов;3) Этотмеханизмпроствизучении.РазработчикамПОнетнеобходимости изучать все нюансы межзадачного взаимодействияконкретной ОС, достаточно навыков использования указанногомеханизма.4) Использование только одного механизма позволяет абстрагироватьсяот конкретной ОС с её многообразием предлагаемых возможностей.ПО становится более платформонезависимым и более простым.5) На этапе разработки БПО указанный механизм может значительнооблегчить его отладку.Отдельно следует сказать по поводу отладки БПО с использованиеммеханизма передачи UDP-пакетов.

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

Эта же особенность применяется при разработкепрограммного обеспечения цифрового моделирующего комплекса (ЦМК), окотором написано в главе 4.36Фактически, каждая отдельная задача БПО может быть запущена нацелевой платформе, при этом все её окружение (источники входных данныхи приёмники выходных данных) может быть имитировано на КПА. Такойспособ отладки БПО позволяет быстро и эффективно обнаруживать иошибки в задачах, тем самым уменьшая общее время, затрачиваемое наотладку.1.6Логика работы системы управления движением инавигацией в режиме трёхосной ориентации аппаратаБортовая подзадача СОиС КА является циклически исполняемой,работающей под управлением операционной системы реального времени(ОСРВ) на базе операционной системы (ОС) Linux.

Цикл задачи выбранравным 100 мс, исходя из цикла работы применяемого интегрирующегогироскопа – самого быстродействующего с точки зрения полученияинформации прибора.Каждый цикл задача последовательно выполняетследующие действия [4]:1. обработка сигналов от бортовой задачи, реализующей циклограммуработыаппарата,идрайверовизмерительныхприборовиисполнительных органов;2. выполнение действий инициализации (установка режима ориентации,инициализация параметров режима, считывание установочных матриц,считывание программы ориентации);3. первичная обработка данных, полученных от драйверов устройств(перевод измерений в связанную систему координат, фильтрацияизмерений и проч.);4.

запуск диспетчера режима ориентации;5. расчёт управляющих сигналов на исполнительные органы и передачаих в драйверы устройств;6. формирование массивов телеметрических параметров.Бортовая подзадача БНО выполняет следующие действия:37 приём сигналов от бортовых задач СОиС, Логики и GPS/ГЛОНАССприёмника; обработку траекторных измерений GPS/ГЛОНАСС-приёмника; формирование массивов телеметрической информации; формирование массивов для задачи СОиС, включающих в себя данныео фазовом векторе КА, орте Земля-Солнце, матрице перехода из СКJ2000 в орбитальную СК.Как видно из п. 4, в главном цикле задачи осуществляется запускдиспетчера режима.В подзадаче СОиС реализованы два диспетчера режимов: диспетчеррежима демпфирования и диспетчер режима трёхосной ориентации.Диспетчер режима демпфирования состоит из одного единственногоподрежима, поэтому не нуждается в детальном описании.

Основу подрежимадемпфирования составляют алгоритмы, представленные в подразделе 1.11.Диспетчер режима трёхосной ориентации обеспечивает переключениемежду различными способами счисления текущей программы ориентации,его функциональная схема представлена на рисунке 1.3. В качестве средствадля оценки параметров вектора состояния используется наблюдательЛюенбергера, являющийся, по сути, частным случаем фильтра Калмана,применениекоторогорассмотренов[3,7].ОтличиемнаблюдателяЛюенбергера от фильтра Калмана является использование постоянныхкоэффициентов фильтра.38Рисунок 1.3 – Схема алгоритма трёхосной ориентации КА «Аурига»Поясним обозначения на рисунке 1.3:Λ – кватернион ориентации КА по информации звёздного датчика,̅ – вектор магнитной индукции Земли, в проекции на оси аппарата,̅ – вектор угловых скоростей вращения двигателей-маховиков впроекции на оси аппарата;̅ – приращение угла за цикл подзадачи СОиС по данным гироскопа;Q – кватернион ориентации аппарата по данным гироскопа;̅– отклонения текущей ориентации от программно-заданной натекущем цикле подзадачи СОиС в каналах управления по данным звёздногодатчика;̅– отклонения текущей ориентации от программно-заданной натекущем цикле подзадачи СОиС в каналах управления по данным гироскопа;̅̂ – апостериорная оценка отклонения текущей ориентации отпрограммно-заданной на текущем цикле подзадачи СОиС в каналахуправления;̅ – вектор управляющих сигналов на магнитные исполнительныеорганы;39̂ – апостериорная оценка отклонения текущей угловой скорости̅вращения от требуемой на текущем цикле подзадачи СОиС в каналахуправления;̂ – апостериорная оценка суммарного вектора возмущающих̅воздействий, действующих на КА;̂̅ –апостериорнаяоценкадрейфаизмеренийгироскопапоинформации звёздного датчика.Выбор наблюдателя динамической системы именно в таком видеобусловлен характеристиками шумовых составляющих измерительныхустройств в зависимости от условий функционирования [2].

Так например,шумовая составляющая выходной информации звёздного датчика при углеотстройки от направления на Солнце 35° практически двукратно превосходитшумы, реализуемые при углах более 60°. Аналогичная ситуация отмечается угироскопа,нашумыкотороговлияеттемпературнаястабильностьпосадочного места и многие другие трудно прогнозируемые факторы. Такимобразом, при недостаточно точно известных характеристиках шумовойсоставляющей ошибки измерения, которая изменяется в зависимости отусловий функционирования КА на интервале витка, было принято решениеотказаться от более сложного в бортовой реализации фильтра Калмана снестационарной ковариационной матрицей ошибок в пользу наблюдателяЛюенбергера с постоянными коэффициентами усиления.Результаты моделирования показали, что применение наблюдателяЛюенбергера позволяет достичь требуемых характеристик по точности присущественноболеепростойреализациибортовогопрограммногообеспечения.Управление малого КА ДЗЗ «Аурига» осуществляется по информациизвёздного датчика без использования в формировании управляющихсигналов данных ГИВУС, пока данные поступают хотя бы с одного иззвёздных датчиков.

При этом параллельно осуществляется непрерывная40калибровка ГИВУС, и если в процессе разворотов КА данные со звёздныхдатчиков перестают поступать – алгоритм автоматически начинает обработкуданных с ГИВУС, базируясь на последних полученных данных о егосистематическом дрейфе. Работа наблюдателя динамической системы, безучёта калибровки ГИВУС, формализуется следующими соотношениями [1]:1. Прогноз углового движения в трёх каналах управления определяетсясоотношением̅̅̅(1.7.1).где()[(())]))]([̅̅[[(̅]]̅̅[ ̅ ]̅̅[]̅[]T – такт задачи системы ориентации и стабилизации КА;̅ – априорное значение расширенного вектора состояния системы наi-м такте;̅– априорные значения углового отклонения от требуемойориентации на i-м такте;̅ – априорные значения отклонения от требуемой угловой скоростина i-м такте;̅ – апостериорные значения возмущающих ускорений на i-м такте;Mx,y,z, i – управляющие сигналы на исполнительные органы на i-м такте.412.