CC BY
8
УДК 550.34
ПРОГРАММНОЕ УПРАВЛЕНИЕ СЕТЕВЫМ КОМПЛЕКСОМ СБОРА И ОБРАБОТКИ ГЕОФИЗИЧЕСКИХ ДАННЫХ
Илья Николаевич Матвеев
Новосибирский государственный технический университет, 630073, Россия, г. Новосибирск, пр. К. Маркса, 20, магистрант, тел. (913)469-55-14, e-mail: ilmat192@gmail.com
Марат Саматович Хайретдинов
Институт вычислительной математики и математической геофизики СО РАН, 630090, Россия, г. Новосибирск, пр. Академика Лаврентьева, 6, главный научный сотрудник, тел. (383)3308743; Новосибирский государственный технический университет, 630073, Россия, г. Новосибирск, пр. К. Маркса, 20, е-mail: marat@opg.sscc.ru
В работе описывается схема организации модульной архитектуры программного комплекса для сбора и обработки геофизических данных в режиме реального времени. Модули представляются в виде отдельных программ, взаимодействующих с программным комплексом посредством стандартных потоков ввода/вывода. Описывается схема для передачи модулям как исходных данных, так и команд.
Ключевые слова: сейсмология, программная система, удаленный сбор и обработка данных, обработка в реальном времени, модульная архитектура, межпроцессное взаимодействие.
THE SOFTWARE CONTROL OF THE NETWORK SYSTEM FOR GEOPHYSICAL DATA COLLECTING AND PROCESING IN REALTIME MODE
Ilya N. Matveev
Novosibirsk State Technical University, 630073, Russia, Novosibirsk, 20 Prospekt K. Marksa, student, tel. (913)469-55-14, e-mail: ilmat192@gmail.com
Marat S. Khairetdinov
Institute of Computational Mathematics and Mathematical Geophysics, Siberian Branch of RAS, 630090, Russia, Novosibirsk, Lavrentiev Ave, 6, Senior Researcher; Novosibirsk State Technical University, 630073, Russia, Novosibirsk, K. Marksa Ave 20, tel. (383)330-87-43, е-mail: marat@opg.sscc.ru
The scheme of modular architecture organization of software system for geophysical data collecting and processing in realtime mode is described in the article. It's suggested to design modules as separate programs which interact with the system via standard input/output streams only. The way to transfer to module not only data to process but also commands is described.
Key words: seismology, software system, remote data collection and processing, realtime data processing, modular architecture, interprocess communications.
На сегодняшний день одним из перспективных направлений в сфере геофизического мониторинга является переход от постобработки данных к обработке в реальном времени. Системы, направленные на поточный сбор и обработку, обеспечивают оперативное получение результатов натурных экспериментов.
Подобная программная система разрабатывается на базе ИВМиМГ СО РАН. Одним из основных требований к ней является возможность расширения и модификации для решения различных задач. Это обеспечивается за счет выбора модульной структуры системы, в которой данные, подлежащие обработке, проходят через вычислительный конвейер, состоящий из отдельных модулей. Каждый модуль выполняет некоторую обработку данных и передает их следующим. Модуль выполняется в виде отдельной программы, запускающейся в отдельном процессе и взаимодействующей с другими модулями с помощью средств межпроцессного взаимодействия, предоставляемых операционной системой. В качестве метода передачи данных используются UNIX-сокеты, как более быстрый и универсальный способ по сравнению с каналами (pipes) [1]. Такой подход позволяет разработчику модулей абстрагироваться от устройства системы в целом и использовать практически любой доступный ему язык программирования и программный инструментарий.
В простейшем случае для передачи данных достаточно использовать стандартные потоки ввода и вывода, которые, в той или иной форме, доступны для подавляющего большинства современных языков программирования. В таком случае перед запуском конвейера потоки всех модулей соединяются в нужной последовательности с использованием UNIX-сокетов. После этого все модули начинают принимать данные с входов, обрабатывать их и передавать результаты на выходы. При завершении работы конвейера всем процессам посылается сигнал останова, который они могут перехватить, выполнить процедуры подготовки к останову и штатно завершиться. Также в таком случае не предъявляется каких-либо сложных требований к внутренней организации модулей. Они не должны предпринимать никаких дополнительных действий для установления соединения друг с другом, поскольку используются стандартные ввод и вывод, доступные изначально. Единственное, что требуется от модуля - поддерживать формат передачи данных, которой также весьма прост и может представлять собой, например, последовательность амплитуд сигнала, замеренных с определенной частотой дискретизации.
Вместе с тем, при использовании данной схемы появляется ряд сложностей. Ключевой из них является сложность управления уже запущенным конвейером. Под управлением в данном контексте можно понимать изменение структуры самого конвейера (переподключение модулей в другом порядке), а также изменение параметров модулей (это могут быть некоторые параметры алгоритмов обработки данных, например ширина скользящего окна) и посылку им иных команд (например, команды отобразить графический интерфейс пользователя). Задачу изменения структуры конвейера без его останова можно решить, используя отдельный процесс управления, который будет перенаправлять потоки данных между модулями [1]. В этом случае каждый модуль в конвейере передает данные не непосредственно своему соседу, а контрольному процессу, который, в свою очередь, транслирует данные нужному модулю.
Передача модулям команд и параметров достигается путем создания отдельного канала связи между контрольным процессом и процессом прикладно-
го модуля. Однако, такой подход накладывает дополнительные ограничения на структуру прикладного модуля: он должен будет самостоятельно организовать канал межмодульного взаимодействия для передачи команд. В качестве такого канала можно также использовать UNIX-сокет, но это существенно ограничивает выбор языков программирования для разработки модулей (к примеру, в Java нет возможности подключиться к UNIX-сокету без использования сторонних библиотек). Использование для передачи данных соединения на основе именованных каналов также имеет свои сложности и требует от прикладного модуля открытия файла канала и чтения из него. Поэтому вместо того, чтобы использовать для передачи отдельный канал межмодульного взаимодействия, было решено передавать команды через стандартный ввод вместе с данными. Для осуществления этого требуется несколько изменить формат передачи данных, разбив поток отсчетов на пакеты. Каждому пакету в таком случае можно добавить поле «тип». В зависимости от этого поля модуль сможет идентифицировать пакет как пакет команды или пакет данных.
Также разбиение данных на пакеты позволяет реализовать схему с несколькими входами или выходами для одного модуля. При этом каждый пакет помимо данных также несет номер входа, на который он направлен. В таком случае выходы одного модуля могут быть связаны с входами нескольких других, что делает систему более гибкой. Более того, выделив понятие «входа модуля» мы можем отказаться понятия «тип пакета» заменив его понятием «тип входа». В этом случае каждый модуль помимо входов данных, количество которых зависит от задач модуля и определяется его разработчиком, имеет дополнительный вход команд, используемый для передачи модулю параметров и команд. Соответственно имеет модуль и выход команд, предназначенный для передачи процессу управления данных откликов на команды. Структура пакета представлена на рис. 1, обощенная схема передачи команд и данных - на рис. 2.
Номер входа (1 байт)
Тело пакета
Рис. 1. Обобщенный вид пакета
В зависимости от типа входа, на который пришел пакет, тело пакета интерпретируется как данные подлежащие обработке или команды, подлежащие выполнению. Формат тела пакета данных представлен в табл. 1, формат тела пакета команды - в табл. 2. Возможные типы аргументов команды представлены в табл. 3. При этом сама команда имеет тип «строка» и передается соответствующим образом.
Также вводится набор базовых команд, которые должны поддерживать все модули (табл. 4). На выход команд модуль выдает отклик на каждую команду. На данный момент доступно только два отклика: ok (модуль успешно выполнил команду) и err (произошла ошибка). Отклик err имеет два параметра - целочисленный код ошибки и ее строковое описание. Отклик ok может иметь различные аргументы в зависимости от команды. Каждый модуль, доступный для до-
бавления в конвейер описывается текстовым конфигурационным файлом в формате JSON. В нем перечисляются доступные команды модуля, его параметры и их типы (аналогичны типам из табл. 2, входы и выходы.
Рис. 2. Схема передачи данных между модулями с использованием промежуточного процесса
Таблица 1
Формат тела пакета данных
Поле Тип данных
Начало записи Время первого отсчета пакета в секундах от начала эпохи UNIX. Тип данных -double
Частота дискретизации uint32_t
Число каналов Количество логических каналов в данных пакета. Тип данных - uint32 t
Значение отсчета 1 канала 1 double
Значение отсчета 1 канала 2 double
Значение отсчета 1 канала N double
Значение отсчета 2 канала 1 double
Таблица 2 Формат тела пакета команды
Поле Тип данных
Команда Команда в виде строки. Формат передачи строки см. ниже
Аргумент 1 Тип аргумента 1
Таблица 3
Типы аргументов команд и формат их представления
Тип Описание
int Целое, int32_t
double Вещественное, double
boolean Логический, int8 t
string Строка. Сначала длина (int32_t), потом массив символов (wchar t)
Таблица 4
Базовые команды
Команда Аргументы команды Аргументы отклика ок Описание
start - - Запуск обработки данных
stop - - Приостановка обработки данных
kill - - Останов модуля
set Параметр (строка), Значение (тип зависит от типа параметра) Устанавливает значение параметра (например, частоту дискретизации, имя выходного файла и т.д.)
get Параметр (строка) Значение (тип зависит от типа параметра) Выдает на командный выход значение параметра
Командный вход и выход имеется у любого модуля и не требует описания в конфигурационном файле.
При запуске процесс управления читает конфигурационные файлы, заполняя структуры для дальнейшей работы с модулями. Во время работы процесс управления может создавать дочерние процессы для отдельных модулей. При этом создаются все необходимые ЦМХ-сокеты, на которые перенаправляются потоки ввода/вывода дочернего процесса. После этого в адресном пространстве дочернего процесса стартует и приступает к обработке пакетов данных и команд процесс прикладного модуля.
На сегодня разработан макет системы для использования в экспериментальных исследованиях.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Хайретдинов М.С., Матвеев И.Н. Организация сетевой архитектуры в задачах геофизического мониторинга // Труды XI международной азиатской школы-семинара «Проблемы оптимизации сложных систем» 27 июля - 07 августа 2015г. - г. Чолпон-Ата, 2015г. - т.2. -с.645-651
© И. Н. Матвеев, М. С. Хайретдинов, 2016
