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

 

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

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

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

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

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

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

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

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

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

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

. Орбита:

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

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

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

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

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

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

Общая масса платформы ~ 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	Разработчик
2003	AAUSat-I	RTX166	Aalborg University
	CanX-I	None	University of Toronto Institute for Aerospace Studies
	DTUSat	eCos	Technical University of Denmark
	QuakeSat	Linux OS	Stanford University and Quakefinder
2005	NCUBE-2	nCX	Norwegian University of Science and Technology
2006	ION	ION OS	University of Illinois
	Merope	Linux	Montana State University
	NCUBE - 1	Vertex	Norwegian University of Science and Technology
	Libertad-1	Salvo Pumpkin	Universidad Sergio Arboleda
2008	AAUSat-II	eCos	Aalborg University
	CanX-2	CANOE OS	University of Toronto Institute for Aerospace Studies
	Cute-1.7+APD II	Microsoft Windows CE.net	Tokyo Institute of Technology
	Delfi-C3	Delfi-C3 OS	Delft University of Technology
	BeeSat	Tiny BOSS	Berlin Institute of Technology
	HawkSat	HISS OS	Hawk Institute for Space Sciences
	ITUpSAT	ITU SSDTL OS	Istanbul Technical University
	SwissCube	eCos	Ecole Polytecnique Federate de Lausanne
2010	Rax-1	Salvo Pumpkin	University of Michigan
2011	DICE	Salvo Pumpkin	Utah State University
	M-Cubed	Linux OS	University of Michigan
2012	e-st@r	Salvo Pumpkin	Politecnico de Torino
	Goliat	Salvo Pumpkin	University of Bucharest
	Robusta	μC/OS-I	University of Montpellier

 

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

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

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