Аппаратное хранилище данных на борту космического аппарата*

*Работа выполнена в рамках реализации конкурса научно-технических исследований, разработок, инновационных программ и проектов для обеспечения конкурентных преимуществ экономики Красноярского края (Дополнительное соглашение от 05.07.2012 г. № 03/12 к Соглашению № 5 от 06.08.2009 г.)

Лукин Феликс Александрович – аспирант Сибирского государственного аэрокосмического университета имени академика М.Ф. Решетнева. (г.Красноярск)

Шахматов Александр Владимирович – инженер Сибирского государственного аэрокосмического университета имени академика М.Ф. Решетнева (г.Красноярск)

Аннотация: Рассматривается необходимость создания и принципы функционирования аппаратного хранилища телеметрии в составе бортовой сети SpaceWire космического аппарата. Анализируются преимущества данного подхода. Приводится предлагаемая архитектура для реализации данного хранилища на языке описания аппаратуры интегральных схем VHDL.

Ключевые слова: База данных, комплексы бортового управления, бортовая сеть, телеметрия, программируемые логические интегральные схемы, система на кристалле.

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

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

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

Для реализации СУБД предполагается использование специального аппаратного блока представляющего собой оконечное устройство, работающее по протоколу SpaceWire RMAP (Remote Memory Access Protocol). Контроллер СУБД входит в состав и управляется КИС. КИС принимает команды телеуправления с Земли, выделяет из них запросы контроллеру СУБД и передает их в очередь запросов контроллера СУБД.  Запросы постепенно выполняются исполнителем и возвращаются на Землю в виде пакетной телеметрии. Сущность концепции пакетной телеметрии состоит в том, что данные различных процессов бортовых систем КА объединяются в пакеты данных, соответствующие источникам, которые затем передаются по каналу передачи так, чтобы принимающие средства с высокой надежность могли восстановить их [2]. Возможно использование специальных отложенных запросов, которые выполнятся в определенное время, в случае наличия связи с Землей. Таким образом, реализуется запросовый канал телеметрии, с помощью которого осуществляется, управляемая  выдача телеметрии. Снижаются риски потери телеметрических данных за счет введения транзакционности на каждый запрос. Записи из БД удаляются только после получения квитанции о доставке на Землю, в противном случае они продолжат храниться дальше, до следующей выборки.

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

БД представляет собой набор файлов: таблиц и индексов, связанных между собой. Каждый файл таблицы или индекса содержит заголовок с атрибутами и набор кортежей. Заголовок содержит служебную информацию, о количестве строк в таблице, о размере одной записи, о название полей и так далее. Контроллер СУБД реализует базовые операции выборки и фильтрации. Поддерживается операции CRUD, фильтрация (SQL аналог - WHERE) осуществляется по маске (маска задается через регистры контролера СУБД) с параметрами. Поддерживаются как скалярные запросы (результат вычисления которых помещается в специальный выходной регистр контроллера СУБД), так и строковые (с внешним интерфейсом памяти, с возможностью построчного чтения, как с ожиданием чтения данных, так без него). Поддерживаются агрегатные функции AVG, SUM, а также DISTINCT, TOP и другие.

Более крупные запросы и обработку результатов вычисления выполняет непосредственно сама КИС.

Алгоритмы работы всех входящий в состав СУБД блоков, таких как контроллер памяти, контроллер файловой системы, контроллер запросов, а также входящее в эти блоки множество кэшей, неизменны и поддаются успешной унификации и реализации на ПЛИС. Множество элементарных операций (например, расчеты различных относительных адресов и так далее) требуют множество процессорных инструкций, что в свою очередь делает решения на базе микропрограммы для встроенного процессора не оправданными. Решение на базе ПЛИС в виде «системы на кристалле» является наиболее подходящим для реализации данной архитектуры.

Преимущества архитектуры СУБД на базе аппаратного решения в виде «системы на кристалле» включают в себя: максимально возможную производительность по сравнению с микропрограммным решением, а также возможность использования СУБД декодером команд телеуправления прозрачно - без микропрограммы для КИС, в резервном режиме, для исполнения аппаратных команд. Архитектура «системы на кристалле» является оптимальной по скорости, по сравнению с микропрограммным решением в составе встроенного микропроцессора. Это достигается за счет того, что, минуя конвейер процессора (исполняющий микропрограмму с функциями СУБД) конечный автомат аппаратного контроллера СУБД, напрямую работает с данными, что является заведомо максимально быстродействующим вариантом. Более того, решение основанное на аппаратных блоках является весьма предсказуемым в плане времени исполнения. Расчет таймингов работы блоков с линейным быстродействием не составляет труда, чего не скажешь о решениях основанных на связке «микропроцессор + микропрограмма», где производительность является зависимой от микропрограммы, а значит плавающей и трудно прогнозируемой.

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

Список литературы:

1. Никитин Д.А., Ханов В.Х., Вергазов М.Ю., Чекмарев С.А. Сетевая архитектура бортового комплекса управления: В трудах российской конференции «Технические и программные средства систем управления, контроля и измерения» УКИ-12 [Электронный ресурс] – М.: ИПУ РАН, 2012 – с. 1539-1546.
2. Современная телеметрия в теории и на практике. Учебный курс. – СПб.: Наука и техника, 2007. – 672 с.
3. Шурыгина В. Энергонезависимая память. Кто победит в гонке? Часть 2. // Электроника: наука, технология, бизнес. 2008, № 6.  с.36-47.

Интересная статья? Поделись ей с другими: