РАЗРАБОТКА БАЗЫ ДАННЫХ ПЕРЕМЕННОЙ СТРУКТУРЫ

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

Посмотрим на рисунок:

Рисунок 1. Структура сообщений

На нем представлены сообщения, которые могут передаваться по шине. Каждое слово должно начинаться с сигнала пословной синхронизации и иметь 17 информационных разрядов, включая разряд контроля четности. Сообщения, которые передаются по информационной магистрали, должны иметь форматы, соответствующие форматам основных или групповых сообщений. Форматы сообщений, отличные от указанных в ГОСТ, применять не рекомендуется.

Рисунок 2. Форматы передаваемых слов

На рисунке 2 указаны форматы сообщений, передаваемых по шине МКПД. В задаче, которая была поставлена по созданию базы данных, используются только форматы номер 1, 2 и 4. При разработке программных модулей для работы с базой данных магистрального канала общения встала задача выбора формата данных для хранения в базе.

Первым и, очевидным вариантом, будет хранение всех слов просто напрямую в базе данных, а именно: дата, адрес, подадрес, номер магистрали, количество слов, командное слово, бит направления передачи, ответное слово, бит признака основная/резервная линия. Однако, если обратиться к рисунку 1, то можно заметить, что часть данных, которые выбраны для записи в базу уже содержатся в командном слове: адрес, подадрес, количество слов, бит направления передачи. Эти данные можно доставать напрямую из командного слова с помощью арифметического сдвига. При создании второго программного модуля отталкивались от цели не хранить избыточную информацию на диске. На рисунке 3 представлен фрагмент кода, на котором показано, как получаются поля из командного слова.

Рисунок 3. Арифметический сдвиг командного слова

При помощи таких операций легко достается нужная часть слова.

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

Тест №1 проводился на тестовом журнале объемом 13 Мб. После переноса журнала в базу данных через первый модуль получили файл размером 2.727 Мб, в котором хранятся те же данные, что и в искомом журнале. Разница между тестовым журналом и первым модулем составляет почти 4,76 раз.

После переноса журнала в базу при помощи второго модуля, база данных получилась размером 2,08 Мб. Разница с исходным вариантом хранения в 6,25 раза. Посмотрим на времена доступа к базе в разных местах на графике ниже.

График 1. Тест базы размером 13 Мб

На графике слева направо приведены времена доступа к данным в следующих местах базы: 1) общее время открытия базы; 2) время доступа к записи в начале файла; 3) время доступа к записи в середине файла; 4) время доступа к записи в конце файла; 5) время доступа от конца файла к записи в начале файла.  Разница в скорости доступа между контроллерами равна 1.34 раза.

Во втором тесте использовался тестовый журнал объемом 327 Мб. Получившиеся базы для первого и второго модулей занимали объем 89.727 Мб и 81.629 Мб соответственно. Разница по памяти между модулями составляет порядка 9%. Далее на графике приведены времена доступа к записям в базе для первого и второго модуля данных аналогично тесту №1.

График 2. Тест базы размером 327 Мб

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

Тест №3 проводился на журнале размером 1.31 Гб. После переноса данных в базу с помощью первого модуля объем базы получился равным 244 Мб, а для второго модуля 222 Мб. Разница в объеме около 9%.

График 3. Тест базы размером 1.31 Гб

Исходя из полученных результатов, было решено отказаться от варианта хранения сжатой структуры данных, так как при увеличении объема данных, выигрыш по памяти остается такой же в сравнении с хранением всех слов в обычном формате. Для повышения быстродействия был разработан третий программный модуль, использующий для хранения сообщений в базе структуру из первого модуля. В новом модуле для массива записей БД МКО запрашиваются заранее соответствующие бортовые времена, а поиск соответствующего времени происходит внутри программы, а не в базе. Этим сокращается число запросов к базе бортовых времен. Далее представлены графики тестов 1, 2, 3 по очереди, но на них добавлены времена доступа к данным третьего контроллера.

График 4. Сравнение модулей на файле 13 Мб

График 5. Сравнение модулей на файле 327 Мб

График 6. Сравнение модулей на файле 1.31 Гб

По графикам видно, что время доступа к данным сократилось в среднем в 7 раз по сравнению с первым контроллером. По результатам работы были разработаны 3 программных модуля для работы с базой данных МКО, используя различные структуры хранения данных. По результатам тестирования был выбран оптимальный программный модуль с точки зрения быстродействия и потребления памяти.

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

1. ГОСТ Р 52070-2003
2. https://docs.microsoft.com/ru-ru/visualstudio/
3. https://docs.mongodb.com/
4. http://doc.qt.io/