Бортовой управляющий комплекс сверхмалой космической платформы

• Список сокращений
• Введение
• 1 Систематизация задач и выбор схемы построения бортового управляющего комплекса
• 1.1 Анализ типовых функций БКУ сверхмалой космической платформы
• 1.2 Обоснование схемы построения и выбор элементной базы реализации БКУ
• 1.3 Выбор способа кроссплатформенной программной реализации функций БКУ
• 2. Разработка кроссплатформенной программной реализации бортового управляющего комплекса
• 2.1 Разработка SF-модели алгоритма приема и обработки командно-программной информации
• 2.2 Разработка SF-модели алгоритма сбора и обработки телеметрической информации
• 2.3 Разработка SF-модели алгоритма управления системой энергоснабжения
• 3. Практическая реализация бортового управляющего комплекса в базисе ПЛИС FPGA
• 3.1 Создание лабораторного макета БКУ сверхмалой космической платформы
• 3.2 Автоматическая генерация кода конфигурации ПЛИС на базе модели БКУ
• 3.3 Верификация кода конфигурации по технологии Model-Based Design
• Заключение
• Список использованных источников

Список сокращений

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

С учетом новизны предлагаемого подхода для отечественных разработчиков и наличия определенной степени недоверия к технологии Model-based Design со стороны заказчиков ПО, актуальным является подтверждение функциональности автоматически сгенерированного в среде MATLAB ПО.

Целью работы является выбор концепции построения бортового управляющего комплекса научно-образовательной микроспутниковой платформы, а также его программная реализация по технологии Model-Based Design. Для достижения поставленных целей в работе решаются следующие задачи: выбор схемы построения на основе анализа распространено-используемых, разработка имитационной модели в среде Simulink и Stateflow, автоматическая генерация HDL кода и его верификация, отработка кода конфигурации на лабораторном макете.

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

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

В третьем разделе решается задача практической реализации созданного программного обеспечения для работы бортового управляющего комплекса в базисе ПЛИС. Проводится верификация моделей по технологиям Model-Based Design с использованием лабораторного макета. Также рассматривается вопрос о проблемах автоматической генерации HDL-кода из имитационной модели Simulink.

Материалы работы прошли апробацию на всероссийских научно-технических конференциях «Молодежь. Техника. Космос» и «Инновационный арсенал молодежи», опубликованы в сборниках «Молодежь. Техника. Космос: труды IV Общероссийской молодежной науч. — техн. конф. / Балт. гос. техн. ун-т. — СПб.; 2012. (Библиотека журнала „ВОЕНМЕХ. Вестник БГТУ“, № 15)»; «Инновационный арсенал молодежи: труды III науч. — техн. конф. / ФГУП «КБ «Арсенал»; Балт. Гос. Техн. ун-т. — СПб.; 2012» .

1 Систематизация задач и выбор схемы построения бортового управляющего комплекса

1.1 Анализ типовых функций БКУ сверхмалой космической платформы

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

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

Основные системы КА [1]:

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

2. Система управления движением и навигации или, в другой интерпретации, система ориентации и управления движением, предназначенная для управления движением КА как материальной точки, так и для управления угловым движением КА.

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

4. Система бортовых измерений, предназначенная для сбора, обработки и передачи в наземный комплекс управления (НКУ) телеметрической информации о результатах измерений, характеризующих состояние систем КА и протекающие на КА процессы. В её состав входят датчики, формирователи сигналов, устройства обработки данных.

5. Бортовая аппаратура служебного канала управления или командной радиолинии, представляющая собой радиотехнический комплекс для обеспечения своевременного обмена служебной информацией между НКУ и бортовым комплексом управления (БКУ). Система радиоуправления предусматривает организацию процесса приема команд на выполнение разовых операций или временных программ, а также передачу подтверждений об их выполнение: кодирование/декодирование сообщений; прием/передача сообщений; передача подтверждений о выполнении команд, о занесении в память временной программы.

6. Объединенная двигательная установка, состоящая из комплекта двигателей для обеспечения перемещения КА относительно орбиты и углового движения КА.

7. Система обеспечения теплового режима КА.

8. Система энергоснабжения для нормализации процесса электропитания. Состав задач: преобразование первичной (солнечной) энергии в электрическую; управление перенаправления питания аккумуляторной батареи и солнечной батареи; сглаживание пульсаций; распределение питания на устройства КА.

9. «Аварийная» система. В случае возникновение фатальных ошибок БКУ она позволяет пересылать «малую» (т.е. ограниченный набор) телеметрию через «маяк» и выполнить перезагрузку основной системы.

10. Система внутреннего контроля и функционирования контролирует правильность функционирования БКУ в целом с помощью схемы контроля за зависанием (Watch dog). Также она реализует взаимодействие БКУ с полезной нагрузкой КА: дистанционное включение/отключение ПН, сбор телеметрической информации с ПН.

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

Одним из видов спутников современного поколения являются спутники формата CubeSat, выполненные в виде куба или нескольких соединенных между собой кубов с длиной грани равной 10 см. Для подобных аппаратов предъявляются повышенные требования к БКУ, в частности из-за мелких размеров платформы, повышенной радиационной и термо — опасности. Исходя из этого БКУ данного вида спутников должны обеспечивать большинство функций, присущих большим КА.

Таким образом, задачами, выполняемыми БКУ являются:

· Коммутация питания устройств и приборов.

· Управление ориентацией и стабилизацией.

· Контроль работоспособности аппаратуры бортовых систем КА.

· Реализация функций телеметрической системы.

· Прием и обработка командно-программной информации, поступающий из БРТК.

· Управление системой полезной нагрузки.

· Реализация циклов автоматического функционирования и парирования внештатных ситуаций.

1.2 Обоснование схемы построения и выбор элементной базы реализации БКУ

Один из проектов, разрабатываемых на кафедре «Радиотехника и телекоммуникации» Санкт-Петербургского государственного политехнического университета совместно с конструкторским бюро «Арсенал» и Балтийским государственным техническим университетом «Военмех», является проект «Синергия», предусматривающей разработку сверхмалой космической платформы для создания наноспутников научного и технологического назначения.

Одним из стандартов разработки сверхмалых космических аппаратов является стандарт CubeSat, предопределяющий основные физические параметры проектируемого СМКА. Форма — куб со стороной 100×100×100 мм, основной материал как правило алюминиевый сплав. Масса модуля — порядка 1 кг и объемом 1 литр, обозначается модуль — 1u. Известны реализации таких СМКА на базе нескольких соединенных вместе кубов. Такие конфигурации обозначаются, соответственно, 2u — для двойных и 3u — для тройных конфигураций.

К настоящему времени определен технический облик платформы как сверхмалого космического аппарата, выполненного по технологии CubeSat в конфигурации 1u, и состоящего из 1 куба объемом 1 дм³ (рисунок 1.1, 1.2).

Рисунок 1.1 — Внешний облик наноспутника формата Cubesat платформы «Синергия»

Рисунок 1.2 — Конструкция базового блока платформы «Синергия»

Многоцелевая унифицированная платформа «Синергия» блочно-модульного типа, предназначена для обеспечения проведения научных, образовательных и технологических экспериментов в условиях космического пространства. «Синергия» представляет собой СМКА, состоящий только из служебных подсистем. В зависимости от космической миссии платформа может быть доукомплектована научной аппаратурой под конкретные задачи [2,3].

Подобное технологическое решение имеет ряд преимуществ:

· высокая взаимозаменяемость элементов платформы как следствие модульного принципа организации подсистем;

· выполнение широкого спектра наукоемких исследовательских задач;

· блочно-модульный принцип построения позволяет коренным образом видоизменять форм-фактор конечного изделия на любых этапах проектирования или сборки СМКА.

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

Технические характеристики платформы «Синергия» :

1. Орбита:

Солнечно-синхронная.

Высота: 300 — 1500 км.

Наклонение: 96−100^о.

Околокруговая, эксцентриситет е < 0,01.

2. Массогабаритные характеристики:

Размеры: 100×100×100 мм.

Общая масса платформы ~ 1 кг.

Масса полезной нагрузки ~ 10−70% от общей массы.

3. Энерговооруженность:

Мощность солнечных батарей: 3,3 Вт.

Емкость аккумуляторных батарей: 22 Ач.

Энергопотребление платформы: 0,01 А (режим ожидания), 1,2 А (работа).

4. Система связи:

Скорость передачи данных: 76 кбит/с.

Диапазон частот командной радиолинии: 145 МГц (приём) / 435 МГц (передача).

Вид модуляции: GMSK.

Метод кодирования: каскадное.

Стандарт формирования кадров: CCSDS.

Частота передачи радиомаяка: 435 МГц.

5. Срок активного существования: 1 … 5 лет.

6. Диапазон рабочих температур:

Внутриаппаратная: — 40^о … +60^оС.

Снаружи аппарата: — 55^о … +75^оС.

7. Устойчивость к перегрузкам: до 6 g.

8. Воздействующее излучение:

Протоны, электроны.

Максимальная накапливаемая доза: 37,4 Крад.

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

БКУ КА содержит в себе главный управляющий модуль (ядро), устройство запоминания информации, устройства связи между подсистемами, а также собственно сами подсистемы, реализованные в том или ином виде. Существует 2 способа построения БКУ: с использованием централизованной или распределенной структуры.

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

Рисунок 1.3 — Пример централизованной схемы реализации БКУ КА

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

Предложено создать БКУ, используя централизованную архитектуру построения. Центральный процессор выполняет запрос телеметрической и целевой информации от подсистем с заданной периодичностью или по запросу с наземного комплекса управления (НКУ), запись её в бортовое запоминающее устройство, извлечение для пересылки в устройство приема/передачи информации, получение разовых команд и временных программ, их обработка и воздействие на определенные внутренние или внешние исполнительные механизмы. Радиотехническая часть служит для взаимодействия с наземным комплексом управления. Маяк, представляющий собой независимую подсистему, выполняет роль аварийного передатчика. Имея собственный источник питания, данная подсистема опрашивает определенный набор датчиков КА на предмет возможной неисправности, и независимо от бортового комплекса управления в целом постоянно передает информацию на наземный комплекс управления в кодировке Морзе.

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

Рисунок 1.4 — Пример распределенной схемы реализации БКУ КА

Предложена концепция построения БКУ в формате «системы-на-кристалле» в базисе программируемой логики (рисунок 1.5).

В этом случае большинство устройств БКУ (центральный процессор, контроллеры памяти, шин и др.) конфигурируются в ПЛИС, что ведет к сокращению массогабаритных характеристик и энергопотребления, а также к повышению надежности аппаратуры из-за уменьшения числа внешних соединений [5,6].

Рисунок 1.5 — Структурная схема центрального процессора в формате «системы-на-кристалле»

Бортовой компьютер любого КА необходим для выполнения разнообразных задач, а также для обеспечения связи с наземным центром управления. БКУ тесно связан со всеми подсистемами и, следовательно, требует определенного уровня системной интеграции. Если говорить о СubeSat, где пространство и мощность являются крайне важными критериями, БКУ выполняет подавляющее большинство всех вычислительных задач, остальные задачи решаются «на местах» (к примеру, кодирование радиосигнала, хранение информации, управление режимом питания, реализующиеся, соответственно, в подсистеме командной радиолинии, устройстве хранения информации, подсистеме электропитания). В сочетании с различными датчиками, расположенными по всему КА, измеряющими определенный набор характеристик (температура, напряжение, ток), БКУ, получая телеметрическую информацию, использует её для расчета необходимых поправок, призванных максимально расширить возможности точности. БКУ разрабатывается в соответствии с основными функциями системы, диктующие необходимость и дизайн встраивания того или иного элемента. В связи с подавляющим отсутствием энергетических и других ресурсов, ясно, что минималистский дизайн с точки зрения энергопотребления необходим. Это также диктует выбор центрального процессора, определяющего потенциал необходимый операционной системы.

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

Таблица 1.1 — Использования операционных систем реального времени в наноспутниках

результате анализа спутников CubeSat (таблица 1.1) было выявлено, что большинство разработчиков использовали свободную в доступе операционную систему Linux: некоторые создавали свою на базе уже имеющихся, другие — закупали коммерческую. Все операционные системы служат общей цели — для контроля аппаратных средств и для реализации необходимых приложений. Операционная система реального времени (RTOS) оптимизирована для получения результатов в промежуток времени, который позволяет информации быть еще уместной и точной. Однако все RTOS имеют различные функциональные возможности, которые и определяют их область применения в том или ином КА [2,5,7]. Из материалов таблицы видно, что даже для спутников, имеющим одинаковый форм-фактор и, возможно, схожий набор подсистем, используют различные RTOS, чья область применимости определяется требованиями самой ОС к электронной начинке КА. Главная задача бортовой системы обработки данных состоит в контроле за КА в целом и выполнении команд в течение всего полета, в обязательном порядке — корректного.

Практически во всех описанных бортовых комплексах управления наноспутниках для контроля работы аппаратуры используется операционная система. Предложена концепция построения БКУ на конечных автоматах, отказавшись при этом от ОС. При анализе этих двух подходов не было выявлено существенных преимуществ или недостатков. Основным критерием выбора ОС являлось наличие многозадачности, многопоточности. Однако, технологическая структура ПЛИС подразумевает возможность создания системы с использованием параллельных процессов.

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

1.3 Выбор способа кроссплатформенной программной реализации функций БКУ

Новшеством, предлагаемым в работе, является автоматическая разработка программного обеспечения БКУ по технологии Model-based design.

Model-Based Design (модельно-ориентированное проектирование) — эффективный и экономически выгодный способ разработки систем управления, обработки сигналов и изображений, построения систем связи, разработок в области мехатроники и создания встраиваемых систем. Вместо физических прототипов и текстовых спецификаций в модельно-ориентированном проектировании применяется исполняемая модель. Эта модель используется во всех этапах разработки. При таком подходе можно разрабатывать и проводить имитационное моделирование как всей системы целиком, так и ее компонентов. Есть возможность автоматической генерации кода, испытаний в непрерывном режиме и верификации.

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

Основой этого метода служит компьютерное моделирование в системе Matlab-Simulink-Stateflow, которое позволяет реализовать все этапы модельно-ориентированного программирования — от учета требований к разработке до тестирования конечного продукта. Пакет Simulink представляет собой различные блоки устройств, взаимодействующие между собой. Пакет Stateflow позволяет смоделировать и разработать конечную автоматную модель, а затем использовать её как блок Simulink-модели.

Почти 60% FPGA и ASIC требуют повторной сборки после устранения функциональных дефектов. Продукт компании MathWorks для генерации HDL-кодов, косимуляции (совместного моделирования) и проверки помогают успешно справиться с этой задачей.

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

Simulink можно использовать для разработки моделей систем, содержащих цифровые, аналоговые и программные элементы. Simulink HDL Coder позволяет быстро найти компромисс между мощностью аппаратуры и скоростью вычислений. Выбирая подходящую конвейерную обработку и архитектуру, разработчик получает лучшую аппаратную реализацию своего алгоритма. Выбирать можно, к примеру, между каскадной, последовательной и древовидной реализациями. Чтобы учесть требования изменившейся спецификации, достаточно изменить модель Simulink и автоматически сгенерировать код HDL. Моделирование системы на высоком уровне абстракции позволяет повторно использовать разработку, делает проект транспортабельным и независимым от целевой платформы. К примеру, разработчик может использовать библиотеку моделей Simulink, быстро получая для каждого варианта модели код HDL, не редактируя при этом сам код Verilog или VHDL. Кроме того, проект можно сделать доступным для нескольких команд. И, наконец, возможно прототипирование на ПЛИС и массовая реализация на прикладных интегральных схемах.

Встроенная утилита HDL Coder генерирует HDL-код под заданное устройство. Важнейшее преимущество концепции Model-based-design проявляется на данном этапе. Оно заключается в следующем: при смене целевой микросхемы нет необходимости переписывать код программы, как это делается в традиционной методике построения систем, достаточно лишь изменить при генерации кода параметр назначенного устройства. За счет данного кросс-платформенного метода работа сокращается в десятки раз по времени, что уж говорить о трудоемкости.

Разработка и верификация программного обеспечения для БКУ космических аппаратов является сложной многоуровневой задачей, выполнение которой в настоящее время занимает годы. Существует возможность снизить это время за счет автоматизации разработки ПО на базе средств и методов компании MathSoft, обеспечивающих процесс автоматической генерации программных кодов для выбранных аппаратных платформ из визуальных моделей StateFlow и Simulink среды MATLAB.

Разработка ПО сводится, таким образом, к построению визуальных моделей управляющих алгоритмов, проверке их адекватности с использованием моделей источников сигналов и генерации программного кода, оптимизированного под особенности аппаратной платформы (процессоры, контроллеры, ПЛИС) [12,13].

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

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

Модельно-ориентированное проектирование — это новый метод для решения всего комплекса перечисленных задач в рамках единой среды разработки на платформе MATLAB/Simulink. Этот метод объединяет разные этапы разработки системы, такие как формирование спецификаций и системных требований, имитационное моделирование, разработка системы, отладка и тестирование в непрерывный рабочий процесс (рисунок 1.6).

Рисунок 1.6 — Этапы разработки систем в среде Simulink

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

Среда проектирования MATLAB и Simulink позволяет быстро создавать алгоритмы в виде математических моделей и выбирать наиболее оптимальный вариант алгоритма. Нет необходимости сразу писать на С или HDL (и тратить недели на проверку той или иной реализации) до того, как выбран удовлетворяющий вариант.

Одним из этапов является автоматический синтез C и HDL кода и верификация непосредственно на отладочных платах. Данный процесс разработки носит название модельно-ориентированное проектирование (Model-Based Design) и применяется во многих российских конструкторских бюро как единый инструмент проектирования цифровых систем обработки сигналов. Основные функции, выполняемые в данной среде: проектирование систем цифровой обработки сигналов в MATLAB и Simulink — введение в System Objects, потоковая обработка информации с помощью System Objects, ускорение алгоритмов цифровой обработки сигналов; перенос и проверка алгоритмов на FPGA — автоматическая генерация С кода, автоматическая генерация HDL кода, проверка алгоритмов в режиме Software-in-the-loop и FPGA-in-the-loop.

Таким образом, на данном этапе работы были решены следующие задачи: в качестве используемой была выбрана централизованная схема построения внутренней структуры бортового комплекса управления; было принято решения отказаться от использования операционных систем реального времени в пользу конечных автоматов; кросплатформенность программного обеспечения будет выполнена с помощью технологии Model-Based Design, предусматривающей автоматическую генерацию кода конфигурации под практически любую из существующих ПЛИС.

2. Разработка кроссплатформенной программной реализации бортового управляющего комплекса

2.1 Разработка SF-модели алгоритма приема и обработки командно-программной информации

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

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

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

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

Действия — это реакции моделируемой системы на события. Подобно событиям, действия принято считать мгновенными.

Состояние — условия, в которых моделируемая система пребывает некоторое время, в течение которого она ведет себя одинаковым образом. В диаграмме переходов состояния представлены прямоугольными полями со скругленными углами.

Переход — изменение состояния, обычно вызываемое некоторым значительным событием. Как правило, состояние соответствует промежутку времени между двумя такими событиями. Переходы показываются в диаграммах переходов линиями со стрелками, указывающими направление перехода. Каждому переходу могут быть сопоставлены условия, при выполнении которых переход осуществляется. С каждым переходом и каждым состоянием могут быть соотнесены некоторые действия. Действия могут дополнительно обозначаться как действия, выполняемые однократно при входе в состояние; действия, выполняемые многократно внутри некоторого состояния; действия, выполняемые однократно при выходе из состояния.

При проектировании моделей реактивных систем Stateflow используется вместе с Simulink и по желанию — с RTW (Real-Time Workshop) под управлением MATLAB. Совокупность всех Stateflow блоков в модели Simulink — это машина. При использовании Simulink вместе с Stateflow для моделирования, Stateflow генерирует S-функцию для каждой Stateflow машины, чтобы поддерживать моделирование. Этот сгенерированный код для моделирования называется sfun кодом Stateflow. Если необходима работа модели в реальном масштабе времени, Stateflow Coder позволит сгенерировать целочисленный или с плавающей точкой код, основанный на Stateflow машине. RTW сгенерирует код для Simulink части модели и обеспечит структуру для выполнения сгенерированного кода Stateflow в реальном масштабе времени. Код, сгенерированный Stateflow Coder включен в код, сгенерированный RTW. Вы можете получить код, сгенерированный обоими продуктами для специфической платформы. Этот сгенерированный код — специфический RTW-код, который в пределах Stateflow называется rtw кодом.

Данная часть работы тесно связана с реализующийся подсистемой бортового радиотехнического комплекса. Модель данной подсистемы представлена на рисунке 2.1.

Рисунок 2.1 — Имитационная модель системы бортового радиотехнического комплекса, созданного в программе Simulink

Выбран протокол стандарта CCSDS (Consultative Committee for Space Data Systems) — Международный Консультативный Комитет по космическим системам передачи данных. Комитет занимается разработкой стандартов и рекомендаций для космических информационных систем. Целями комитета являются: развитие возможностей взаимодействия между различными космическими агентствами и уменьшение стоимости разработок космических проектов. С момента своего основания комитетом активно разрабатывались рекомендации для: уменьшения для различных агентств стоимости общеизвестных процессов обработки данных; продвижения совместимости и общей поддержки среди взаимодействующих агентств с целью уменьшения расходов на эксплуатацию систем с использованием общих возможностей.

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

Выбор этого протокола был обусловлен следующими соображениями: CCSDS является открытым и, следовательно, может использоваться в любительской спутниковой службе (первые прецеденты уже известны); CCSDS обеспечивает существенно более высокую помехозащищенность передаваемой информации из-за использования наиболее передовых методов канального кодирования (так, по сравнению с модемами MOBITEX модем CCSDS обеспечивает энергетический выигрыш практически на 9 дБ, что позволяет вести передачу на скоростях от 76,8 кбит/с и выше); CCSDS является международным стандартом, поддерживаемым всеми космическими агентствами мира — реализация БРТК «Синергии» в соответствии с этим стандартом будет способствовать повышению доверия потенциальных заказчиков к возможностям платформы.

Состав кадров протокола CCSDS приведен в таблицах 2.1 и 2.2.

Таблица 2.1 — Состав TM кадра протокола CCSDS

Таблица 2.2 — Состав TC кадра протокола CCSDS

Кадр телеметрии состоит из 5 основных полей: основной заголовок фрейма (48 битов), вторичный заголовок фрейма (необязательный 16, 24, 512 битов), поле данных (переменной длины), поле операционного управления (необязательное), поле контроля ошибок (обязательное, если не применяется код Рида-Соломона). Все фреймы с одним номером версии и идентификатором объекта, передающиеся по одному физическому каналу, составляют главный канал. Главный канал объединяет восемь виртуальных каналов. Имеется пять основных функций основного заголовка фрейма передачи: идентификация блока данных поля фрейма передачи, идентификация объекта, мультиплексирование виртуальных каналов в главный канал, подсчет фреймов виртуальных каналов и главного канала, передача указательной и другой управляющей информации. Номер версии фрейма содержится в битах 0−1 основного заголовка, имеет значение 00, что идентифицирует данный блок данных как фрейм. Затем следует поле идентификация фрейма, которое идентифицирует источник фреймов, принадлежащий ему виртуальный канал, и сдержит информацию о формате пакетов. Идентификатор спутника — 10 битное поле, обозначающее аппарат, передающий фреймы. Идентификатор виртуального канала (3) обеспечивает идентификацию виртуального канала. Всего 8 виртуальных каналов в пределах главного. Идентификатор управления (1) указывает на присутствие или отсутствие поля управления. Это «1», если данное поле присутствует, и «0», если отсутствует. Счетчик кадров основного канала это 8-разрядное поле должно содержать двоичное значение каждого кадра, переданного в основном канале (0.255). Счетчик кадров виртуального канала (8) это 8-разрядное поле должно содержать двоичное значение каждого кадра, переданного в виртуальном канале (0.255). Состояние поля данных кадра передачи (16) указывает, присутствует ли вторичный заголовок, несет информацию о типе данных, информацию, необходимую для извлечения пакетов из поля данных фрейма. Это 16-разрядное поле должно быть подразделено на пять подполей следующим образом: Отметка вторичного заголовка (1) определяет присутствие или отсутствие вторичного заголовка кадра передачи. Это «1», если вторичный заголовок присутствует, и «0», если отсутствует. Метка синхронизации (1) — область, определяющая тип данных, содержащихся в поле данных. Оно устанавливается в «0», если в поле данных находятся пакеты источника, сегменты или неинформативные данные. Флаг порядка пакета (1) устанавливается в 0, если флаг синхронизации 0, а при значении 1 флага синхронизации устанавливается произвольное значение. Идентификатор длины сегмента (2) принимает следующие значения: 00 — 256 октетов, 01 — 512, 10 — 1024 окт., 11 — только сегментированные пакеты. Указатель основного заголовка (11) содержит двоичное значение номера первого октета, 1 в поле данных пакета или сегмента при 0 флага синхронизации. Если фрейм не содержит заголовка пакетов, то устанавливаются все единицы. Если содержатся неинформативные пакеты, то устанавливается 11…10.

Так как одно из основных требований — безошибочная доставка данных (достоверность передачи) для их защиты от ошибок, используется кодирование канала, как способ передачи данных по зашумленному каналу, позволяющий безошибочно восстанавливать их на приемной стороне. Основной задачей помехоустойчивого кодирования является решение проблемы обеспечения высокой достоверности передаваемых данных за счет применения устройств кодирования/декодирования в составе системы передачи цифровой информации. Для обеспечения помехозащищенности используется каскадный код, который состоит из кода Рида-Соломона (255, 223, 33), сверточного кода с K=7 и R=½ и прямоугольного перемежителя, представляющего собой массив (кодовые слова кода Рида-Соломона построчно записываются в массив перемежителя, а затем считываются по столбцам и кодируются с помощью кодера сверточного кода). В случае отсутствия кода Рида-Соломона в кадре содержится поле контроля ошибок, которое используется для обнаружения и исправления ошибок, которые появляются в процессе обработки и передачи данных. В стандарте определяется метод синхронизации кадров передачи с помощью использования синхронизирующего маркера, с которого начинаются фреймы. В случае приема ошибочного сообщения посылается квитанция обратной связи, после чего сообщение повторно отправляется.

Разработанная модель, предназначенная для приема и обработки командно-программной информации представлена на рисунке 2.2.

Рисунок 2.2 — Модель приема и обработки командно-программной информации При входе в алгоритм обработки командно-программной информации происходит сброс константы kvi, отвечающей за квитирование приходящих данных. Решающая обратная связь используется в данном алгоритме для корректности и своевременного обнаружения ошибок при работе БКУ. Согласно данному алгоритму в процессе обработки команды переменная kvi может принимать три различных значения: «0» — по умолчанию, «1» — отсутствии переданной команды в базе данных реализуемых в КА и «2» — положительный ответ о наличии таковой.

Работа блока начинается с передачи с бортового радиотехнического комплекса (БРТК) разрешающего значения на порт входа trig. В случае подачи «1» активируется вложенное состояние On1 (рисунок 2.3).

Алгоритм начинается с записи в локальную переменную comm непосредственной информации о принятой и декодированной в БРТК разовой команде. Затем происходит её опознавание согласно внутренней базе данных команд (таблица 2.3).

Таблица 2.3 — Реализуемые команды

Рисунок 2.3 — Вложенная модель приема и обработки командно-программной информации.

Согласно данным командам выдаются соответствующие команды: включение/отключение полезной нагрузки — передача 1/0 на порт выхода PL, который впоследствии будет соединен с микроконтроллером, расположенным в подсистеме полезной нагрузки; переход в режим экономии электроэнергии — присваивание порту вывода energy значения «1», соединенного с микроконтроллером системы энергоснабжения (СЭС); сброс телеметрической информации — включение алгоритма работы с памятью.

Поскольку кадр должен состоять из 1764 символов, то из памяти будут последовательно считываться 1764 бита и записываться в локальную переменную sBUF. В случае нехватки символов, оставшееся место будет заменено логическими нулями. По окончанию набора 1764 символов информация локальной переменной sBUF выдается на порт выхода BRTK, связанной со входом БРТК.

2.2 Разработка SF-модели алгоритма сбора и обработки телеметрической информации

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

Блок контрольно-измерительных приборов включает в себя следующие виды датчиков: температурный датчик, инфракрасный датчик, акселерометр, магнитометр, гироскоп, компас. Подробное их описание представлено в таблице 2.4.