Разработка архитектуры встраиваемой СУБД малых космических аппаратов Текст научной статьи по специальности «Компьютерные и информационные науки»

Информатика, вычислительная техника и управление

УДК 004.65: 629.7.05

РАЗРАБОТКА АРХИТЕКТУРЫ ВСТРАИВАЕМОЙ СУБД МАЛЫХ КОСМИЧЕСКИХ

АППАРАТОВ

Ю.В. Конкин, А.Н. Колесенков

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

Ключевые слова: база данных, СУБД, спутник, предварительная обработка, бортовой

Введение

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

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

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

Малая производительность космических вычислительных машин частично объясняется

Конкин Юрий Валериевич - РГРТУ, канд. техн. наук, доцент, e-mail: konkinjv@yandex.ru

Колесенков Александр Николаевич - РГРТУ, канд. техн. наук, доцент, e-mail: sk62@mail.ru

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

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

Обычно при разработке МКА используют специализированное системное программное обеспечение, создаваемое для каждого конкретного космического аппарата. Рынок предлагает широкий выбор готовых к использованию базовых аппаратно-

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

В последнее время ситуация в этой области меняется в сторону использования тиражируемых БСУ [5]. Возрастающие потребности в компьютеризации на борту МКА, на которых могут устанавливаться сотни

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

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

Для организации хранения и оперативного доступа к данным на борту МКА необходимо использовать системы управления базами данных. Стандартные базы данных, такие как SQL, достаточно требовательны к ресурсам вычислительной машины, что делает затруднительным или невозможным использование их в качестве бортовых СУБД [6].

Постановка задачи

Разработка бортовой системы управления базой данных (СУБД) для задач хранения и обработки информации на МКА вызвана следующими причинами [7]:

- низкая мощность вычислительной системы на борту МКА;

- ограничение по объему оперативной памяти и постоянных запоминающих устройств;

- при вводе и изменении структурированной информации необходимо обеспечивать целостность данных;

- для одновременного использования СУБД несколькими задачами необходимо предусмотреть многопользовательский доступ к БД;

- отсутствие бортовых вариантов СУБД с необходимыми характеристиками.

В существующих бортовых СУБД перечисленные выше возможности для обработки данных представлены не полностью или вообще отсутствуют.

Архитектура СУБД

В бортовой СУБД предлагается использовать реляционную модель данных и многоуровневую структуру памяти:

- внешняя энергонезависимая память, обеспечивающая сохранение базы данных

после выключения питания;

- оперативная память, в которую загружается база данных для выполнения запросов, добавления, изменения и удаления данных;

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

В физической структуре базы данных можно выделить следующие компоненты:

- таблицы данных;

- хранимые записи;

- первичные ключи (для идентификации хранимой записи в таблице);

- уникальные ключи (для исключения повторов значений выбранных атрибутов записи в таблице);

- внешние ключи (для организации ссылочной целостности).

Исходя из вышесказанного рассмотрим следующие известные методы доступа с точки зрения их использования в данной задаче:

- хеширование;

- последовательный поиск;

- бинарный поиск;

- поиск в бинарном дереве.

Анализ перечисленных выше методов доступа показывает, что условиям задачи наиболее соответствует метод бинарного выровненного дерева для доступа по первичному, уникальному или внешнему ключу. В целях сокращения объемов используемой памяти можно отказаться от индексирования по внешнему ключу и выполнять поиск записи при проверке ссылочной целостности последовательным просмотром таблицы [8].

С учетом особенностей бортовых вычислительных систем в архитектуре СУБД (рис. 1) можно выделить две подсистемы:

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

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

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

Анализ возможных структур

вычислительных систем, а также задач, в которых планируется использовать БД, показывает, что разделение транзакций приложений может быть обеспечено следующими способами:

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

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

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

Рис. 1. Архитектура бортовой СУБД

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

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

приложением;

- загрузить БД в память каждого приложения.

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

Во втором случае БД не является распределенной, так как используется только модулем запросов приложений. Запросы обрабатываются в порядке их поступления от приложений. При этом отсутствует конкурентная блокировка данных разными приложениями.

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

Формат данных

Для хранения БД разработан формат, описывающий физическую структуру БД (рис. 2). Формат содержит следующие параметры:

- заголовок базы данных;

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

- дескрипторы полей. В данной структуре для каждого поля указываются наименование, первый байт в физической записи данных, размер поля в байтах, тип поля, номер ключа, в которое входит поле. Анализ предметной области показывает, что типы данных могут быть следующими: BYTE (1 байт), INTEGER (2 байта), LONG (4 байта), FLOAT (4 байта), DOUBLE (8 байт), DATE (4 байта), TIME (4 байта), STRING (1.255 байт);

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

внешний ключ;

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

Рис. 2. Формат физической структуры базы данных

Запись данных содержит информацию о значениях всех полей записи в двоичном коде, соответствующем типу данных поля. Для получения значений записей в порядке следования по ключу в структуре записи предусмотрены поля, содержащие информацию о местонахождении записи во всех деревьях индексов, по которым индексировалась запись. Такая структура записи позволяет сократить размер памяти, занимаемый БД, так как не

требуется отдельно хранить значения ключей [11]. В данном случае значения информационных полей и ключей объединены в одной области памяти. Физическая структура записи представлена на рис. 3.

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

Поле 1 . . . Поле M 1 г . . . / г

_______--—-----

Поля данных в двоичном кади

Указатели на узлы двоичного дерева индекса

Рис. 3. Физическая структура записи БД

Рис. 4. Физическая структура списка блоков

Экспериментальная часть

Эксперименты по реализации

разработанной СУБД проводились в среде Microsoft Visual Studio Community с возможностью кросс-платформенного переноса исполняемого кода. Данные, измененные в процессе работы, сохраняются в оперативной памяти, а при необходимости могут быть скопированы в энергонезависимую FLASH-память. На основе данной архитектуры можно организовать как многопользовательский

доступ к разделяемым данным, так и параллельные транзакции, в которых пользователь видит изменения только тех данных, которые сделал он сам.

В результате экспериментальных исследований была создана БД для хранения навигационной информации на борту МКА [12,13]. После проведения анализа описанной выше предметной области выделены следующие сущности:

1. КАРТА - для хранения картографической информации об участке земной поверхности (табл. 1). Здесь Х1^1 -прямоугольные координаты юго-западного угла карты; Х2^2 - прямоугольные координаты северо-западного угла карты; Х3^3 - прямоугольные координаты северовосточного угла карты; Х4^4 - прямоугольные координаты юго-восточного угла карты. Прямоугольные координаты представляются в заданной картографической проекции. Атрибут «Идентификатор карты» выделим в качестве первичного ключа сущности КАРТА.

2. ЭТАЛОН - для хранения информативного участка на карте, используемого в качестве эталона (табл. 2). В^ - широта и долгота привязки на местности центрального элемента разложения эталонного изображения (ЭИ); Х^ - прямоугольные координаты в заданной картографической проекции в метрах для центрального элемента разложения ЭИ [14,15]. Атрибут «Идентификатор эталона» выделим в качестве первичного ключа сущности ЭТАЛОН. Атрибут «Идентификатор карты» выделим в качестве внешнего ключа для организации ссылочной целостности.

Таблица 1

Сущности «Карта»

Атрибут Тип Размер, байт

Идентификатор карты LONG 4

Название карты STRING 8

X1 DOUBLE 8

Y1 DOUBLE 8

X2 DOUBLE 8

Y2 DOUBLE 8

X3 DOUBLE 8

Y3 DOUBLE 8

X4 DOUBLE 8

Y4 DOUBLE 8

Таблица 2

Сущность «Эталон»

Атрибут Тип Размер

Идентификатор эталона LONG 4

Идентификатор карты LONG 4

B DOUBLE S

L DOUBLE s

X DOUBLE 8

Y DOUBLE 8

Заключение

В работе представлена архитектура реляционной СУБД, ориентированная на встраивание в бортовое программное обеспечение МКА. Предложенная архитектура СУБД имеет низкие требования к мощности вычислительной системы и ресурсам памяти на борту МКА.

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

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

Литература

1. Макриденко Л.А. Концептуальные вопросы создания и применения малых космических аппаратов / Л.А. Макриденко, С.Н. Волков, В.П. Ходненко // Вопросы электромеханики. Труды НПП ВНИИЭМ. - 2010. - Т. 114.

- № 1. - С. 15-26.

2. Антамошкин А.Н. Технологические аспекты создания бортового программного обеспечения спутников связи / А.Н. Антамошкин, А.А. Колташев // Вестник Сибирского государственного аэрокосмического университета им. академика М.Ф. Решетнева. - 2005. - № 3. - С. 93-95.

3. Колесенков А.Н. Технология поддержки принятия управленческих решений на основе оперативного мониторинга пожарной обстановки / А.Н. Колесенков // Известия Тульского государственного университета. Технические науки. - 2015. - № 9. - С. 157-163.

4. Конкин Ю.В. Распознавание изображений на основе текстурных признаков харалика и искусственных нейронных сетей / Ю.В. Конкин, А.Н. Колесенков // Известия Тульского государственного университета. Технические науки. - 2016. - № 2. - С. 117-123.

5. Технология создания программных моделей бортовых компьютеров спутников / А.В. Барков, А.А. Колташев, М.В. Тимисков, Н.Н. Шумаков // Наукоемкие технологии. - 2014. - Т. 15. - № 9. - С. 34-38.

6. Тиори Т. Проектирование структур баз данных / Т. Тиори, Дж. Фрай; пер. с англ. - М.: Мир, 1985. - 287 с.

7. Коннолли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг. - М.: Вильямс, 2003. - 1440 с.

8. Кириллов В.В. Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: ВНУ, 2009.

- 464 с.

9. Конкин Ю.В. Система управления базами данных для навигационных комплексов летательных аппаратов / Ю.В. Конкин // Проблемы передачи и обработки информации в сетях и системах телекоммуникаций. -2005. С. 240-241.

10. Дейт К. Введение в системы баз данных / К. Дейт; пер. с англ. - М.: Вильямс, 2002. - 1072 с.

Рязанский государственный радиотехнический университет

EMBEDDED DATA BASE MANAGEMENT SYSTEM ARCHITECTURE DEVELOPMENT

OF SMALL SPACECRAFTS

Yu.V. Konkin1, A.N. Kolesenkov2

'PhD, Associate Professor, Ryazan State Radioengineering University, Ryazan, Russian Federation

e-mail: konkinjv@yandex.ru 2PhD, Associate Professor, Ryazan State Radioengineering University, Ryazan, Russian Federation

e-mail: sk62@mail.ru

A problem of designing database management systems (DBMS) for use on board of small space vehicles is considered. The purpose of the work is to develop the structure of on-board DBMS, description of the principles of functioning of its elements, as well as development of a universal data format. The proposed architecture of DBMS has low requirements for the performance of the on-board computer system and memory resources. Features of DBMS operation with a multilevel memory structure are considered. The components of physical structure of the database are identified. The analysis of access methods shows that the binary aligned tree method for accessing using the primary, unique, or foreign key is the most appropriate one for the task conditions. In order to reduce the amount of memory used, it is suggested not to index the foreign key, and perform record search when checking the referential integrity by sequentially viewing a table. To store data in the database, a format is

l2

developed that describes the physical structure of the database, which contains the parameters necessary for downloading information. The access to the data by the value of a key is based on the algorithm of traversing the binary tree. The experiments on the implementation of the developed database were conducted in the Microsoft Visual Studio Community programming system with possibility of cross-platform transfer of executable code

Key words: database, DBMS, satellite, preprocessing, on-board

References

1. Makridenko L.A., Volkov S.N., Khodnenko V.P. "Conceptual issues of creation and application of small space vehicles", Electromechanical matters. Proc. of VNIIEM studies. (Voprosy elektromekhaniki. Trudy NPP VNIIEM), Moscow, 2010, vol. 114, no. 1, pp. 15-26.

2. Antamoshkin A.H., Koltashev A.A. "Technological aspects of creating on-board software of communication satellites", Siberian Journal of Science and Technology", 2005, no. 3, pp. 93-95.

3. Kolesenkov A.N. "Technology of supporting the management decisions based on operational monitoring of the fire situation", Proceedings of the TSU. Technical Sciense, 2015, no. 9, pp. 157-163.

4. Konkin Y.V., Kolesenkov A.N. "Recognition of images based on textural signs of haralik and artificial neural networks", Proceedings of the TSU. Technical Sciense, 2016, no. 2, pp. 117-123.

5. Barkov A.V., Koltashev A.A., Timiskov M.V., Shumakov N.N. "The technology of creating software models of satellite onboard computers", High Technologies, 2014, vol. 15, no. 9, pp. 34-38

6. Teorey T., Fry J. "Designing Database Structures", Russ. ed., Moscow, Mir, 1985, 287 p.

7. Connolly T.M., Begg C.E. "Database Systems: A Practical Approach to Design, Implementation and Management", Russ. ed., Moscow, Vil'yams, 2003, 1440 p.

8. Kirillov V.V., Gromov G.Yu. "Introduction to relational database" ("Vvedenie v relyatsionnye bazy dannykh"), Saint Petersburg, BHV, 2009, 464 p.

9. Konkin Yu.V. "Database management system of navigational complexes of aircrafts", Problems of information transferring and processing in networks and systems of telecommunications. Proc. of 14th International Scientific Technological Conference (Problemy peredachi i obrabotki informatsii v setyakh i sistemakh telekommunikatsiy: Tez. dokl. 14-y mezhdunar. nauch.-tekhn. konf. Ryazan. gos. radiotekhn. akad.), Ryazan, 2005, pp. 240-241.

10. Date C.J. "Introduction to Database Systems", Russ. ed., Moscow, Vil'yams, 2002, 1072 p.