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

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

Содержание

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

Введение

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

Заключение

Список использованных источников

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

АБ - аккумуляторная батареяБКУ - бортовой комплекс управленияБРТК - бортовой радиотехнический комплексКА - космический аппаратКИА - контрольно-измерительная аппаратураНКУ - наземный комплекс управленияПЛИС - программируемая логическая интегральная схемаПН - полезная нагрузкаПО - программное обеспечениеРК - разовые командыСАПР - система автоматизированного проектированияСБ - солнечная батареяСМКА - сверхмалый космический аппаратСЭС - система энергоснабженияТМ - телеметрияТМИ - телеметрическая информацияASIC - Application Specific Integrated Circuit (интегральная схема специального назначения) CCSDS - Consultative Committee for Space Data Systems (Международный Консультативный Комитет по космическим системам передачи данных) GMSK - Gaussian Minimum Shift Keying (Гауссова модуляция с минимальным сдвигом частоты) HIL - Hardware-in-the-Loop (аппаратное тестирование в петле) FIL - FPGA-in-the-Loop (тестирование FPGA в петле) FPGA - Field Programmable Gate Array (программируемая логическая интегральная матрица) IP-core - Intelligent Property Core (ядро интеллектуальной собственности) MIL-Model-in-the-Loop (модельное тестирование в петле) MPPT-Maximum Power Point Tracking (отслеживатель максимальной силовой точки) RTOS - Real Time Operation System (операционная система реального времени) RTW - Real Time Workshop (мастерская реального времени) SIL - Software-in-the-Loop (программное тестирование в петле) SF - Stateflow (диаграмма состояний)

Введение

Разработка и верификация программного обеспечения для бортовых комплексов управления космических аппаратов является сложной многоуровневой задачей, выполнение которой в настоящее время занимает годы. Существует возможность значительно уменьшить это время за счет автоматизации разработки программного обеспечения на базе средств и методов компании 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]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. Орбита:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Год запускаНаименование КАRTOSРазработчик2003AAUSat-I RTX166Aalborg UniversityCanX-INoneUniversity of Toronto Institute for Aerospace StudiesDTUSat eCosTechnical University of DenmarkQuakeSatLinux OSStanford University and Quakefinder2005NCUBE-2nCXNorwegian University of Science and Technology2006IONION OSUniversity of IllinoisMeropeLinuxMontana State UniversityNCUBE - 1VertexNorwegian University of Science and TechnologyLibertad-1Salvo PumpkinUniversidad Sergio Arboleda2008AAUSat-II eCosAalborg UniversityCanX-2 CANOE OSUniversity of Toronto Institute for Aerospace StudiesCute-1.7+APD IIMicrosoft Windows CE.netTokyo Institute of TechnologyDelfi-C3Delfi-C3 OSDelft University of TechnologyBeeSatTiny BOSSBerlin Institute of TechnologyHawkSatHISS OSHawk Institute for Space SciencesITUpSAT ITU SSDTL OSIstanbul Technical UniversitySwissCube eCosEcole Polytecnique Federate de Lausanne2010Rax-1Salvo PumpkinUniversity of Michigan2011DICESalvo PumpkinUtah State UniversityM-CubedLinux OSUniversity of Michigan2012e-st@rSalvo PumpkinPolitecnico de TorinoGoliatSalvo PumpkinUniversity of BucharestRobustaμC/OS-IUniversity of Montpellier

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

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

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

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

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

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

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

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

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

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

Simulink можно использовать для разработки моделей систем, содержащих цифровые, аналоговые и программные элементы [11]. 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

При проектировании моделей реактивных систем 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 кодом.

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

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

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

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

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

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

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

Первичный заголовок кадраПоле данных кадра (до 1019 октет) Поле контроля ошибок кадра (16) Номер версии (2) Обходной флаг (1) Контрольный флаг (1) RSVD (2) Идентификатор КА (10) Идентификатор ВК (6) Поле длины фрейма (10) Последовательный номер фрейма (8) Кадр телеметрии состоит из 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 [19].

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

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

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

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

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

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

Команда / действиеКодВключение полезной нагрузки001Отключение полезной нагрузки010Переход в режим экономии электроэнергии011Сброс телеметрической информации из памяти100

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

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

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

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

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

Таблица 2.4 - Описание датчиков, составляющих основу КИА платформы "Синергия"

ДатчикПроизводительМодельПоддержка интерфейсовТемпературный датчикDallas SemiconductorDS1624S+I2cИК датчикMelexisMLX90614ESFI2cАкселерометрBoschBMA150I2c, SPIГироскопInvenSenseIMU-3000I2cКомпасHoneywellHMC6352I2c, SPIМагнитометрHoneywellHMC5883LI2c, SPI

Все датчики выдают цифровую информацию и поддерживают протокол передачи I2c (Inter-Integrated Circuit). Этот интерфейс использует две двунаправленные линии связи - SDA и SCL. Таким образом, подсистема сбора телеметрической информации включает в себя две части - управляющий автомат и программную реализацию интерфейсной части.

Для отработки логики управления и сбора телеметрии при моделировании на лабораторном макете будет использоваться только один датчик - температурный DS1624S+ (рисунок 2.4).

При использовании данного датчика будут задействованы только выводы Vdd, GND, SDA, SCL, отвечающие соответственно за питание, заземление, передачу данных и тактирование. Адресные выводы A0, A1 и A2 использованы не будут, как и NC (No Internal Connection).

Разработка программного обеспечения имеет своей конечной целью создания файла прошивки для ПЛИС. Учитывая это, а также возможности среды разработки ISE Xilinx, целесообразно использовать в качестве отдельных элементов структуры проекта встроенные и/или сторонние IP-ядра (Intellectual Property Core), представляющие собой готовые блоки для проектирования микросхем. Поскольку в стандартных библиотеках среды разработки ISE отсутствует IP-ядро интерфейса I2c, принято решение использовать стороннее бесплатное IP-ядро I2c-master, написанное на языке VHDL (рисунок 2.5), имеющего совместимость с используемой при отладке отладочной платы с ПЛИС Xilinx Spartan-6.

У данного блока имеются следующие входные порты: clock (тактирование, счетное время), reset_n (отвечает за асинхронную перезагрузку ядра), ena (если его значение равно "0" - остановка работы ядра, "1" - включение ядра, загрузка данных с портов addr,rw,data_wr), addr (адрес необходимого slave-устройства), rw ("0" - режим записи, "1" - режим чтения), data_wr (передаваемые данные на устройства); выходные порты: data_rd (считываемые с устройства данные), busy ("0" - индикатор режима ожидания, "1" - индикатор работы ядра), ack_error ("0" - ошибки отсутствуют, "1" - в процессе работы возникли ошибки) - при каждом перезапуске ядра данный буфер накопления ошибок обнуляется.

Также имеется два порта, работающих как на прием, так и на отправку информации - sda (линия данных), scl (линия тактирования).

Логика работы данного ядра представлена на рисунке 2.6 При запуске подсистемы ядро находится в режиме ожидания (состояние ready), при этом постоянно (с заданной частотой clock) считывает информацию с порта ena. В случае, если оно принимает значение "0" - состояние зацикливается само на себя повторяя обновление информации. Если ena = "1", то ядро начинает свою работу. Вначале происходит обнуление всех регистров и перезапись констант, затем - считывание информации с портов addr, rw (состояние command). Проделав данные операции, система определяет значение параметра rw - чтение/запись. В случае, если rw = "1", то происходит определения устройства по заданному ранее параметру addr, задание констант для работы мастера и непосредственное считывание информации с устройства. Если rw = "0", то выбирается устройство, согласно значению addr и считывание информации с slave-устройства. Данные операции могут прерваться 3 способами. Первый - задание параметру ena значения "0" (система переходит в режим ожидания и прекращает своё функционирование), второй - переназначение параметра rw на противоположный, что влечет за собой переходит в иной режим чтения/записи информации с/на устройство, третий - перезагрузка ядра путем подачи на вход reset_n "0". Отличие третьего от первых двух заключается в том, что при перезагрузке ядра происходит прерывание независимо от текущего состояния системы, обнуление значений data_rd и ack_error, задания значения "1" на выход busy, а в двух первых случаях вначале закончится текущая программа работа, а затем перейдет в необходимое состояние.

В соответствии с циклом работы данного интерфейса разработана простейшая система управления данным интерфейсом (рисунок 2.7). Согласно данной SF-диаграмме работа управляющего автомата представляет собой замкнутый бесконечный цикл, в котором инициализируещее состояние First выдает разрешающее значение "1" на вход данной диаграммы enai2c, которые впоследствии при создание проекта в ISE будет соединен со входом ena IP-ядра I2c. Затем происходит остановка работы интерфейса значением "0" того же порта и снятие действующего значения температуры с выхода data_rd IP-ядра, подающегося на вход data_in управляющего автомата и присвоение локальной переменной data этого же значения. Следующее состояние First3 реализует передачу данных показаний температурного датчика на выход управляющего автомата mem, который будет соединен с отдельным автоматом управления внутренней памятью самой платы.

В соответствии с циклом работы данного интерфейса разработана простейшая система управления данным интерфейсом (рисунок 2.7). Согласно данной SF-диаграмме работа управляющего автомата представляет собой замкнутый бесконечный цикл, в котором инициализирующее состояние First выдает разрешающее значение "1" на вход данной диаграммы enai2c, которые впоследствии при создание проекта в ISE будет соединен со входом ena IP-ядра I2c. Затем происходит остановка работы интерфейса значением "0" того же порта и снятие действующего значения температуры с выхода data_rd IP-ядра, подающегося на вход data_in управляющего автомата и присвоение локальной переменной data этого же значения. Следующее состояние First3 реализует передачу данных показаний температурного датчика на выход управляющего автомата mem, который будет соединен с отдельным автоматом управления внутренней памятью самой платы.

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

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

Поскольку было принято решение об использовании при отладке только одного температурного датчика. Реализация полного алгоритма представлена на рисунке 2.8.

Алгоритм работы данной SF-диаграммы следующий: поступаемая информация обрабатывается последовательно на предмет превышения порога истинных значений. Для данного датчика они являются +125 и - 55 градусов Цельсия. Заранее оговорено, что датчик работает в целочисленном двоичном режиме передачи информации о температуре (7-разрядный код - значение температуры, 1 бит - знак температуры). Например, значению + 125 градусов Цельсия соответствует код 01111101, - 55 - 11001001, 0 градусов - 00000000. Шаг измеряемой температуры - 1 градус. В итоге, в случае обнаружение выхода измеряемого параметра из интервала допустимых значений к записываемому в память коду прибавляется логическая 1 для последующего декодирования на наземном пункте управления, если нет - то логический ноль.

Логическая "1" при декодировании на НКУ может быть следствием либо неисправности датчика, либо превышения пороговой температуры работы космического аппарата, что маловероятно.

2.3 Разработка SF-модели алгоритма управления системой энергоснабжения

Основными функциями, которые должна выполнять система электроснабжения, являются:

. Получение, хранение, правильное использование энергии.

. Распределение энергии.

. Защита БКУ от перегрузок.

Для получения энергии будут использоваться солнечные батареи. СБ будут располагаться на 5 из 6 сторон спутника, это связано с тем, что одна из сторон может быть задействована под полезную нагрузку [20,21]. СБ будут соединены параллельно, и каждая будет защищена диодом, чтобы энергия не тратилась впустую. Для производства максимальной энергии, используется MPPT - это устройство ищет такое значение напряжения на СБ, чтобы энергия была максимальна. Затем идет соединение с АБ (аккумуляторной батареей) и общей шиной. АБ батарея подключается к СБ через защитную схему. В шине же, задается некоторое значение напряжения, которое потом может быть легко преобразовано к виду, который требует нагрузка, с помощью конвертера. В случае, если меняется нагрузка, для её подключения к СЭС необходимо только добавить нужный конвертер.

Была создана модель простейшей системы электроснабжения наноспутника:

На данной Simulink схеме можно выделить несколько основных компонентов:

1.Solar Panel - модель солнечной батареи, для её работы принимается количество параллельно и последовательно связанных элементов, температура СБ, напряжение на элементе, а также солнечный поток.

2.Battery - представляет собой АБ, можно изменять тип, напряжения, тип АБ, начальный уровень зарядки. Данный элемент из стандартной библиотеки Simulink.

3.Battery_manage - управляющий автомат, принимает значение тока генерируемого СБ, а также уровень заряда АБ.

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

Модель солнечной батареи была создана на основе теоретического представления. Для инициализации же батареи, необходимо задать количество элементов соединенных параллельно и последовательно. Таким образом, задав параметры некоторой батареи, можно узнать мощность, которую она генерирует, узнать, сколько элементов нужно для получения конкретной мощности, а также узнать другие зависимости, например от T. В Simulink уже имеется библиотека с электрическими системами, поэтому имеет смысл сделать модель СБ совместимой с данной библиотекой, для этого применяется элемент Controlled Current Source, который преобразует сигнал идущий с СБ, в совместимый.

В связи с тем, что спутник некоторое время находится на солнечной стороне, а некоторое время на теневой - это вынуждает нас использовать АБ. Однако, АБ обладает рядом характеристик за которыми необходимо следить, а значить требуется создать управляющее устройство. В данном автомате имеется два основных состояния - спутник находится на солнечной стороне Light, на теневой стороне Dark. Состояние Light в свою очередь имеет 2 под состояния, Charge - т.е. в данный момент идет зарядка, и Discharge - т.е. в данный момент батарея не заряжается. Состояние Dark - имеет 3 под состояния - Work, Low_charge, Very_Low. Если батарея заряжена достаточно, т.е. имеет более 10% своей емкости, то происходит работа в автономном режиме. Если случается так, что батарея имеет низкий заряд, т.е. < 10%, то отправляется сообщение на другие системы, о том, что низкий заряд батареи. Если же заряд становится еще меньше, то происходит отключение основной шины от источников питания, т.е. все системы отключаются. Это связано с тем, что Li-ion АБ имеет свойство деградировать при сильном разряде батареи. Можно проанализировать работу на основе выходных данных (рисунок 2.11).

На данном рисунке изображена осциллограмма заряда АБ. В начальный момент заряд составляет 20%, до момента времени 1000 происходит зарядка АБ, и также часть энергии уходит в нагрузку (состояние Light. Charge). В момент времени 1000 спутник переходит на теневую сторону и происходит переключение на работу от аккумулятора (состояние Dark. Work), АБ разряжается, что видно по наклонённой прямой. Далее работа происходит аналогично. Также данный подход к проектированию СЭС подразумевает еще одну интересную особенность. Мы может сделать часть системы настоящими, а часть оставить моделями, затем сделать небольшие изменения в Simulink-схеме и получить работоспособную модель. Это позволяет на любом этапе проверять правильность созданной модели и вносить коррективы в уже существующие или еще создающиеся устройства.

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

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

Разработанная модель представлена на рисунке 2.15.

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

Состояние EnControl реализует функции взаимодействия с блоком обработки разовых команд, приходящих с наземного комплекса управления. При входе в данное состояние внутренней переменной stEN присваивается значение уже известного из предыдущей главы порта вывода данных energy. Далее принимается решение о дальнейшим действии, исходя из значения самой этой переменной: в случае, если stEN=1, то подаются значения "0" на порты вывода PL и SEND, первый из них отключает энергопитания полезной нагрузки космического аппарата, второй - передающую антенну и систему формирования исходящей информации, расположенной в бортовом радиотехническом комплексе; если же stEN=0, то ничего не происходит и состояние перезагружает информацию с порта.

Состояния EnOn и ZenON (также как и EnOn1 и ZenON1) являются зависимыми. Есть возможность реализовать функции, выполняемые ими в одном состоянии, но они разнесены с целью увеличить производительность за счет многопоточности простых задач, а также обеспечения постоянного контроля за напряжением аккумуляторных батарей. Следует сказать, что данные состояния дублируются, поскольку на платформе "Синергия" предусмотрено 2 аккумуляторных батареи, а солнечная батарея представляет собой совокупность нескольких работающих на один контур управления.

Состояние EnOn реализует проверку текущего напряжения на аккумуляторной батареи. Информация в двоичном коде поступает из микроконтроллера СЭС, который считывает её с датчика напряжения. Поскольку максимальное напряжение работы выбрано аккумуляторной литиевой батареи равно 12 В, порог принятия решения был выбран равным половине, т.е.6 В. В случае если текущее напряжения ниже 6 В, активируется состояние ZenOn и управляющий автомат включает заряд от солнечных батареи на данный аккумулятор и отключает питание с него самого. Когда напряжение вновь приходит в норму, происходит перестройка в обычный режим - космический аппарат питается параллельно энергией, запасенной в аккумуляторах и поступающей с солнечных батарей.

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

3. Практическая реализация бортового управляющего комплекса в базисе ПЛИС FPGA

3.1 Создание лабораторного макета БКУ сверхмалой космической платформы

Для создания лабораторного макета была использована отладочная плата Nexys 3 производителя Digilent (рисунок 3.1). Эта плата содержит в себе ПЛИС FPGA Xilinx Spartan 6 (XC6SLX16-CSG324), 16 Мбайт RAM-памяти, 32 Мбайт PRAM памяти, встроенный генератор, настроенный на частоту 100 МГц, четырехразрядный семисегментный индикатор, 8 LED-индикаторов, 8 ручных реле-переключателей, 5 кнопочных переключателей, порты ввода-вывода информации: VGA, VHDC, 4 Pmod, Ethernet 10/100, USB, USB-UART. Структурная схема отладочной платы также приведена на данном рисунке.

Второй составляющий отладочного процесса является плата с напаянными на неё датчиками (рисунок 3.2).

Плата состоит из трех датчиков, чьи ножки подведены к выводам, соответствующим формату физического интерфейса Pmod и интерфейсу обмена данными I2c. Причем отдельно собраны в один контур 2 датчика (магнитометр и акселлерометр), а датчик температуры на другой контур. Сделано это для отработки работы интерфейса I2c с адресацией и без неё. Информация по используемым датчикам приведена в таблице 3.1.

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

ДатчикПроизводительМодельПоддержка интерфейсовНапряжение питанияТемпературный датчикDallas SemiconductorDS1624S+I2c2.7 - 5.5 ВАкселерометрBoschBMA150I2c, SPI2.16 - 3.6 ВМагнитометрHoneywellHMC5883LI2c, SPI3.3 В

Используемый физический интерфейс Pmod является собственной разработкой фирмы Digilent Inc. Поэтому, дополнительная плата с датчиками была выполнена вручную.

Датчик температуры DS1624S+ позволяет измерять температуру в пределах от - 55 до +125 градусов Цельсия, что соответствует условиям, в которых будет находиться аппарат в космическом пространстве. Он позволяет проводить измерения с точностью до 0.5 градуса, однако при его использования был выбран режим, в котором работа происходит только с целочисленным значением показаний. График зависимости ошибки передаваемой информации в зависимости от температуры устройства представлен на рисунке 3.3.

Интерфейс Pmod представляет собой 12-пиновый разъем (рисунок 3.4) со стандартным размером входа, включающим 2 входа для подачи питания (1,7 на рисунке), 2 - для заземления (2,8 на рисунке) и 8 - информационных (3-6, 9-12 на рисунке). Он позволяет работать с напряжением 3.3 В и 5.5 В, что полностью удовлетворяет условиям используемых датчиков. Для использования протокола I2c задействуются порты 1-4 и 7-10 физического интерфейса Pmod. Протокол I2c использует две шины: SDA - шина данных и SCL - шина тактирования, что соответствует портам 3,9 и 4,10 соответственно.

Для проверки работоспособности всего проекта использовалось следующее программное обеспечение: для создания имитационной модели, её программной верификации, перевода в HDL-код - пакеты программ Stateflow, Simulink, HDL-coder системы автоматизированного проектирования и разработки Matlab; для синтезирования файла прошивки ПЛИС, разводки платы - система автоматизированного проектирования Xilinx ISE 13.3; программатор для ПЛИС - Adept. Общий вид лабораторного макета представлен на рисунке 3.5.

Плата подключается к компьютеру с помощью интерфейса USB-prog, что существенно упрощает работу при программировании ПЛИС. Файл прошивки записывается в ПЗУ отладочной платы, что позволяет не терять информацию в случае её отключения.

В итоге, для отладки программного HDL-кода на отладочной плате использовались: порт ввода-вывода информации Pmod, 8 LED-индикаторов для отображения значений температуры в реальном времени, 3 реле переключателя для изменения режима работы конечного автомата.

.2 Автоматическая генерация кода конфигурации ПЛИС на базе модели БКУ

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

Для автоматической генерации HDL кода используется встроенная утилита HDL coder toolbox системы автоматизированного проектирования и разработки Matlab, которая позволяет довольно простыми методами получить необходимый код на заданном языке программирования. HDL Coder генерирует синтезируемый Verilog и/или VHDL код из функций Matlab, моделей Simulink и диаграмм Stateflow. Полученный HDL-код может быть использован для программирования ПЛИС или прототипирования.

В состав HDL Coder входит инструмент под названием HDL Workflow Advisor (помощник по работе с HDL), который автоматизирует программирование ПЛИС компаний Xilinx и Altera. Можно контролировать HDL-архитектуру и реализацию, выделять критические пути и генерировать отчеты об использовании аппаратных ресурсов. Обеспечивается трассируемость между моделью Simulink и сгенерированным VHDL и Verilog кодом, что позволяет верифицировать его для приложений, требующих высокого уровня надежности.

не зависящий от конечного устройства, синтезируемый VHDL и Verilog код;

генерация кода поддерживается для системных объектов и функций Matlab, а также

блоков Simulink;

автоматы Мили и Мура и реализация управляющей логики с использованием Stateflow;

рабочий помощник для программирования плат с ПЛИС компаний Xilinx и Altera;

совместное использование ресурсов и восстановление синхронизации для достижения

компромисса между скоростью и площадью;

интеграция старого кода.

Генерация HDL-кода для ПЛИС происходит в несколько шагов:

создание проекта, комбинируя код Matlab, блоки Simulink и диаграммы Stateflow;

оптимизация модели для достижения требуемых показателей площади схемы и скорости;

генерация HDL-кода с помощью встроенного помощника по работе с HDL для Matlab

и Simulink;

проверка сгенерированного кода с использованием HDL Verifier.

Достигнуть компромисса между занимаемой на кристалле площадью и скоростью работы можно, оптимизировав HDL-код за счет распределенной конвейеризации, потоковой обработки и совместного использования ресурсов. В Matlab имеется возможность воспользоваться улучшенной оптимизацией циклов, заключающаяся в потоковой обработке циклов и развертывании циклов для проектов Matlab, содержащих циклы for или матричные операции. Постоянные массивы и матричные переменные в коде Matlab можно расположить в блоки RAM. В Simulink можно реализовать многоканальные конструкции и техники сериализации, часто встречающиеся в приложениях обработки сигналов и связи.

После синтеза проекта можно просмотреть отчет по времени и выделить в модели Simulink узкие места с ограничениями по времени. Эта интеграция со средствами синтеза позволяет быстро производить рабочие операции и значительно сокращает время проектирования на ПЛИС.

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

выполнение ко-симуляции HDL-кода в Simulink и HDL-симуляторе, таком как Cadence

Incisive или Mentor Graphics ModelSim и Questa;

FPGA-in-the-loop (FIL) - для проверки проекта в Simulink и плате с ПЛИС.

Общая итоговая модель, созданная при помощи пакета Stateflow среды автоматизированного проектирования и разработки Matlab представлена на рисунках 3.6 - 3.9.

Данная модель содержит 3 вложенных состояния - Radio, Telemetry, Energy, что соответствует конечным автоматам, отвечающим за обработку радиокоманд (рисунок 2.2), сбор и обработку телеметрической информации (рисунок 2.3), управление системой энергоснабжения (рисунок 2.4). Логика работы данных Stateflow-диаграмм уже описывалась. Стоит упомянуть лишь о том, что общая структура работы выполнена в виде параллельной декомпозиции, что является неотъемлемой частью современной системы.

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

На этапе изучения утилиты HDL Coder было выявлено, что некоторые стили создания диаграмм Stateflow HDL coder не поддерживает, в частности таблицы истинности и древа if-else с безусловными переходами выше пятого порядка [15]. В соответствии с этим модель была доработана.

Перед началом генерации кода разработчика говорят о необходимости настроить параметры созданной модели для оптимальной работы с HDL кодером. Вручную делать это не представляется целесообразным, поскольку для этого достаточно ввести в командной строке Matlab команду: >>hdlsetup "Имя модели".

Наиболее удобным и простым в реализации способом для генерации HDL кода является использование утилиты HDL Workflow Advisor, позволяющей пошагово произвести генерацию кода (рисунок 3.10).

Первым шагом является установка целевого назначения использования утилиты, а также непосредственно самой аппаратуры, для которой будет генерироваться код (рисунок 3.11). В данной работе используется просто генерация HDL кода для ПЛИС Xilinx Spartan 6 сборки csg324. Дополнительно в этом же диалоговом окне устанавливается конечная директория для сохранения файлов, а также инструмент для синтезирования сгенерированного кода. В случае установки, к примеру программы Xilinx ISE в качестве ПО для отработки кода, появляется дополнительный пункт 4 FPGA Synthesis and Analysis. На данном этапе это не представляет интереса, поскольку в дальнейшем проведена непосредственная генерация кода конфигурации в Xilinx ISE.

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

Третий шаг - установка пользовательских настроек для генерируемого кода (рисунок 3.13). В числе данных настроек: выбор генерируемого кода (VHDL/Verilog); выбор тематики отчетов, создаваемых по результатам генерации; установка наименований для портов тактирующих импульсов, сброса и разрешающего; выбор вида сигнала сброса (синхронный/асинхронный); выбор установок по оптимизации кода; выбор стиля кодирования и комментариев. Стоит сказать, что также на данном этапе возможен выбор непосредственно генерируемых файлов, в числе которых могут быть: HDL код, Testbench код и модель для косимуляции с выбираемым там же симулятором (например Mentor Graphics ModelSim).

Таким образом были сгенерированы три файла: satellite. vhd, Model_HDL. vhd и Model_HDL_pkg. vhd, что соответствует коду для SF-диаграммы и коду высшего уровня иерархии. В случае успешно прохождения всех этапов на экран выводится отчет о процедуре генерации HDL кода (рисунок 3.14).

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

Таблица 3.2 - Сравнительная таблица использования ресурсов ПЛИС для VHDL и Verilog кодов

VHDLVerilogПеремножители1012Сумматоры3241Регистры110109Элементы памяти00Мультиплексоры140134Общая длина кодового текста24752500

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

Таким образом, можно говорить об удачном прохождении этапа автоматической генерации HDL код на основе имитационной модели Simulink/Stateflow. Следующим шагом станет верификация созданного программного обеспечения, генерация файла конфигурации ПЛИС и его проверка на лабораторном макете.

3.3 Верификация кода конфигурации по технологии Model-Based Design

На данном этапе задача состоит в верификации полученного ранее кода по технологиям Model-Based Design. Существует несколько видов данных проверок, а именно:

1.Model-in-the-Loop (MIL) - тестирование модели в режиме симуляции - происходит в среде Simulink, в результате чего на выходе модели при воздействии тестового вектора получаем набор значений.

2.Software-in-the-Loop (SIL) - тестирование программного обеспечения в замкнутом окружении. На данном этапе вся модель, состоящая из блоков Simulink, написанных на языке Matlab, переводится в единый блок S-функции, конфигурируемый на языке C или C++.

.Processor-in-the-Loop (PIL) - тестирование контроллера в отладочном окружении. Сгенерированный по данной технологии код исполняется на целевом процессоре или на эмуляторе набора инструкций.

4.Hardware-in-the-Loop (HIL) - тестирование аппаратно-программного комплекса на тестовом оборудовании. Обычно выполняется в лаборатории как финальный тест перед интеграцией системы и полевыми испытаниями.

5.FPGA-in-the-Loop (FIL) - разновидность технологии HIL, непосредственно реализуемая в базисе ПЛИС.

В данной работе принято необходимым тестирование в режимах SIL и FIL. При проведении верификации SIL откомпилированный и сгенерированный код для локальной операционной системы выполняется в имитационной модели, где целевая модель заменяется на созданный блок Simulink.

Для программного тестирования используется Real-Time Workshop Embedded Coder. В результате удачной генерации модели на экране отображается блок сгенерированной S-функции. S-функция - это описание логики работы модели на языке, понятным Simulink.

При тестировании по данной технологии целевым системным файлом в настройках генерации кода выбирается ert. tlc. В соответствии с этим открывается возможность выбора создания блока для SIL или PIL (рисунок 3.16).

В результате построения инициализируется вызов нового окна Simulink, где создается модель для SIL верификации (рисунок 3.11)ю

Далее в имитационной модели вместо используемой ставится блок SIL и проводится обычная симуляция (рисунок 3.12). В результате верификации по данной технологии результаты полностью совпали с полученными ранее.

Процесс верификации FPGA-in-the-Loop сводится к разработке модульного теста (вектора), получение результатов от воздействия тестового вектора на компонент и сравнение полученных результатов с ожидаемыми результатами (рисунок 3.13) [11].

При проведении процедуры FIL тестовый вектор подается одновременно на Simulink модель и отладочную плату, прошитую кодом компонента через отладочный интерфейс - в данной технологии применяется Ethernet соединение. Результаты работы ПЛИС передаются обратно в модель Simulink и сравниваются с результатами моделирования.

Для создания модели верификации FIL используется утилита FPGA-in-th-Loop Wizard. В результате прохождения всех стадий генерируется FIL блок для модели Simulink и файл прошивки для загрузки на отладочную плату (рисунок 3.14).

Затем в имитационной модели происходит замена на FIL блок и запускается процесс симуляции. При этом данные поступают через Ethernet интерфейс непосредственно на саму отладочную плату, выходные данные снимаются с неё таким же образом.

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

Заключающим шагом стало создание файла прошивки в САПР Xilinx ISE, специально предназначенной для работы с продуктами данной компании-производителя. Данная программа используется для оптимизации кода конфигурации и создания файла прошивки ПЛИС. Таким образом в качестве входных данных используется файла HDL кода, автоматически сгенерированные ранее.

Xilinx ISE представляется собой последовательный набор процедур, предназначенный для оптимизации создаваемого кода конфигурации под задаваемую аппаратную платформу (рисунок 3.15).

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

В результате проведенной работы сгенерированный код VHDL был проверен по технологиям Software-in-the-Loop и FPGA-in-the-Loop, а также был сгенерирован код конфигурации ПЛИС в программе Xilinx ISE, впоследствии загружен на саму отладочную плату и автономно отработан. Таким образом можно сказать, что принятая в данной работе концепция построения бортового комплекса управления может быть реализована. В результате автоматической генерации HDL кода, сгенерированные файлы были использованы для непосредственного формирования кода конфигурации ПЛИС Spartan 6. Стоит сказать, что вполне возможен выбор другой платформы на базисе ПЛИС. При этом кроссплатформенность данного метода обеспечивается утилитами HDL Workfloor Advisor и FPGA-in-the-Loop Wizard, входящими в состав пакета программ Matlab, то есть обеспечена необходимая кроссплатформенность создаваемого программного обеспечения.

Заключение

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

Обоснование и выбор схемы построения бортового комплекса управления выполнены в полном объеме. В результате обзора типичных схем реализации БКУ наноспутников была выбрана централизованная как наиболее компромиссная и простая в реализации. На основе результатов исследования эксплуатируемых КА было принято решения отказаться от использование операционной системы реального времени в пользу концепции построения БКУ на основе конечных автоматов. В соответствии с этим было принято решение о использовании технологии Model-Based Design для разработки программного обеспечения на базе ПЛИС FPGA, поскольку она обеспечит необходимую многозадачность и компактность реализации узлов БКУ.

Поставленная задача разработки имитационной модели в среде Simulink и Stateflow выполнена полностью. В результате была разработана визуальная модель трех подсистем БКУ: приема и обработки командно-программной информации, сбора и обработки телеметрической информации и управления энергоснабжением.

Автоматическая генерация HDL кода выполнена в полном объеме. Успешно проведена верификация на основе технологий Software-in-the-Loop и FPGA-in-the-Loop, подтвердившая функциональность сгенерированного кода VHDL. Был создан лабораторный макет на основе отладочной платы с ПЛИС Xilinx Spartan 6 и платы с датчиками, используемыми на платформе "Синергия". На основе результатов автоматической генерации кода с помощью программы Xilinx ISE был получен код конфигурации ПЛИС. Впоследствии он был загружен в память отладочной платы лабораторного макета и успешно автономно проверен.

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

Результаты работы внедрены при разработке бортового радиотехнического комплекса микроспутниковой платформы "Синергия" ООО "Лаборатория "Астрономикон".

Список использованных источников

1. Микрин Е.А. Бортовые комплексы управления космическими аппаратами и проектирование их программного обеспечения: учебное пособие. М.: Изд-во МГТУ им. Н.Э. Баумана, 2003.336 с.

. Малыгин Д.В. Универсальная платформа "Синергия" блочно-модульного исполнения: Материалы XV Международной конференции "Решетневские чтения". - Красноярск: Изд-во ОАО "ИСС им. М.Ф. Решетнева", 2011. С.377-378.

. Малыгин Д.В. Применение сверхмалых космических аппаратов для исследования стратов: Труды IV Общероссийской молодежной науч. - техн. конф. "Молодежь. Техника. Космос".14-17 марта 2012 года, Санкт-Петербург. - СПб.: Изд-во Балт. гос. техн. ун-та, 2012. С.176-178.

. Микрин Е.А. и др. Принципы построения бортовых комплексов управления автоматических космических аппаратов // Control Sciences. № 3.2004. С.62-66

. Бровкин А.Г., Бурдыгов Б.Г., Гордийко С.В. Бортовые системы управления космическими аппаратами: учеб. пособие. Под ред.А.С. Сырова. М.: Изд-во "МАИ-ПРИНТ", 2010

. Косткин М. и др. Архитектурные и схемотехнические решения вычислительно-управляющих комплексов на основе микросхем программируемой логики. Компоненты и технологии. 2008. № 5

. Гилл А. Введение в теорию конечных автоматов. М.: Изд-во Наука, 1966.272 с.

. Деменков Н.П. Модельно-ориентированное проектирование. Промышленные АСУ и контроллеры. 2008. № 11.

. Model-based design, 4 April 2013, www.wikipedia.com

11. Model-based design, 1994-2013, www.mathworks.com.

12. Toshinori Kuwahara, Felix Bohringer, Albert Falke etc. FPGA-based operational concept and payload data processing for the Flying Laptop satellite / Acta Astronautica 65 (2009).

13. Hans Tiggeler, Tanya Vladimirova, Daixun Zheng, Jiri Gaisler. Experiences Designing a System-on-a-Chip for Small Satellite Data Processing and Control. Surrey Space Centre, University of Surrey, Guildford, UK.

14. Черных И.В. Simulink - среда создания инженерных приложений. М.: Изд-во "Диалог-МИФИ", 2004.491 с.

. Stateflow and Stateflow Coder Users Guide. www.mathworks.com.

16. Stateflow and Stateflow Coder Release Notes, www.mathworks.com.

17. Тенищева T.А., Технический облик бортового радиотехнического комплекс сверхмалой космической платформы "Синергия". "Инновационный арсенал молодежи: труды III науч. - техн. конф. / ФГУП "КБ "Арсенал"; Балт. Гос. Техн. ун-т. - СПб.; 2012".

18. Cubesat Space Protocol, www.wikipedia.com

. AX 25. www.wikipedia.com

20. Savita Nema, R. K. Nema, Gayatri Agnihotri, Matlab / simulink based study of photovoltaic/ modules / array and their experimental verification, INTERNATIONAL JOURNAL OFAND ENVIRONMENT Volume 1, Issue 3, 2010 pp.487-500.

21. California Polytechnic State University, "The Design of an Efficient, Elegant, and Cubic Pico-Satellite Electronics System, 2004.

22. Ветринский Ю.А., Варёнов А.А. Концепция построения бортового информационно-управляющего комплекса научно-образовательного микроспутника // XL неделя науки СПбГПУ: материалы Междунар. науч. - практ. конф.5-10 декабря 2011 года, Санкт-Петербург. Ч.2. - СПб.: Изд-во Политехн. ун-та, 2011. С.24 - 25.

. Варёнов А.А. Визуальное проектирование кроссплатформенного программного обеспечения бортового комплекса управления наноспутника "Cubesat" // Молодежь. Техника. Космос: труды IV Общероссийской молодежной науч. - техн. конф. / Балт. гос. техн. ун-т. - СПб.; 2012. - 380 с. (Библиотека журнала "ВОЕНМЕХ. Вестник БГТУ", № 15). С.241 - 243.