CC BY
61Об унификации обмена данными между разнородными средствами и системами в едином информационном пространстве
Кравченко Максим Викторович
главный системный аналитик акционерного общества «Научно - производственное объединение «Русские базовые информационные технологии», г. Москва, Россия, m.kravchenko@rusbitech.ru
Спиридонов Сергей Иванович
научный сотрудник акционерного общества «Научно - производственное объединение «Русские базовые информационные технологии», г. Тверь, Россия, s.spiridonov@rusbitech.ru
Никитин Александр Станиславович
к.т.н., доцент, начальник отдела акционерного общества «Научно - производственное объединение «Русские базовые информационные технологии», г. Тверь, Россия, a.nikitin@rusbitech.ru
Для обеспечения наиболее полной реализации возможностей войск необходима сквозная автоматизация управления их деятельностью. Автоматизация может быть достигнута дооснащением органов и пунктов управления комплексными средствами автоматизации. Основной проблемой при этом является формирование единого информационного пространства на основе единой автоматизированной системы сбора данных, баз данных, унифицированных протоколов функционального взаимодействия, интегрированных информационных ресурсов. Кроме того имеет значение и то обстоятельство, что автоматизации должны подвергаться принятые на вооружение и включенные в процессы управления разнородные автоматизированные системы военного назначения. А это означает, что их нельзя модифицировать. В статье предложена технология обеспечения унификации обмена данными между разнородными автоматизированными системами военного назначения с использованием информационной модели обмена данными о вооруженном противоборстве. Информационная модель обмена данными о вооруженном противоборстве представляет собой набор стандартов, содержащих описание структуры и формата данных, передаваемых при формализованном обмене данными между автоматизированными системами военного назначения. При этом необходимо обратить внимание на тот факт, что информационная модель обмена данными ни в коем случае не подменяет внутренние модели данных автоматизированных систем, либо информационные модели предметных областей, связанных с военной сферой деятельности. Информационная модель обмена данными о вооруженном противоборстве рассматривается только как язык (набор языков), с помощью которого организуется обмен между автоматизированными системами (т.е. с точки зрения той или иной автоматизированной системы - информационный обмен с внешними системами).
КЛЮЧЕВЫЕ СЛОВА: автоматизированная система; единое информационное пространство; информационная модель обмена данными; обмен информацией; протокол обмена; структура данных.
АННОТАЦИЯ.
Введение
Основной целью создания единого информационного пространства (ЕИП) является повышение эффективности функционирования органов военного управления (ОВУ) за счет совершенствования информационной поддержки процессов управления. С информационной точки зрения ЕИП ВС РФ может рассматриваться как совокупность информационных ресурсов с общими правилами их формирования, формализации, хранения и распространения, а одним из принципов создания ЕИП является унификация и стандартизация, предполагающая, в том числе, применение единых протоколов информационного обмена. Систему обеспечения ЕИП предполагается создавать на базе уже существующей информационной инфраструктуры ВС РФ путем интеграции ее звеньев, то есть в ЕИП должны быть включены различные информационные ресурсы видов ВС, родов войск, военных округов, центральных ОВУ и др [1-10].
Таким образом, концепция ЕИП предусматривает широкомасштабную трансформацию всей системы управления вооруженных сил.
При объединении разнородных автоматизированных средств и систем в ЕИП одной из главных проблем является обмен данными между ними. В области отечественной автоматизации военной сферы существует множество различных протоколов обмена данными, различающихся по используемым подходам, техническим и технологическим решениям, а также структуре и составу передаваемых данных.
Внедрение необходимых технологий для обеспечения непрерывного обмена информацией в системе управления является крайне важным элементом в ходе реализации современных и перспективных форм и способов ведения боевых действий. Функциональная совместимость автоматизированных систем разведки, управления войсками и оружием, а также обеспечение устойчивого взаимодействия между ними рассматриваются в качестве ключевых компонентов, необходимых для достижения информационного превосходства и, как следствие, превосходства в выработке и принятии решений с целью решительного упреждения противника по всему циклу боевого управления.
Задача облегчается, если данные определенного класса будут перемещаться между системами при условии, что в этих системах будет заложена технологически реализованная возможность воспринимать извне и отдавать наружу данные в едином формате импорта/экспорта. Данный подход является основой для разработки метаданных и интерфейсов для обмена данными для разнородных систем с использованием информационной модели обмена данными о вооруженном противоборстве (ИМОД) [11].
При этом концептуальными положениями целесообразно считать следующие:
- все данные, предназначенные для обмена, агрегируются (конвертируются) по правилам информационной модели обмена данными в файлы формата ИМОД. Если в ИМОД отсутствуют требуемые сущности и (или) правила, то дорабатывается ИМОД. Под термином «агрегирование» понимается не только преобразование сведений о сущностях в ИМОД-файл по правилам ИМОД, но так же объединение данных, связанных между собой одним или несколькими признаками, в конечный перечень (например, документ). В роли таких объединяющих признаков могут выступать, например, формализованные части боевых приказов, распоряжений и донесений, типы донесений из табеля срочных донесений, формализованные описания объектов вооруженного противоборства, формализованные описания физико-географических условий, картографической информации и т.п. Одним из существенных требований к агреги-
рованию является требование заблаговременного (до внедрения в эксплуатацию) объединения конечных перечней сущностей и поддержание их (перечней) в неизменном составе на все время эксплуатации автоматизированной системы военного назначения (АС ВН);
- АС ВН — «источник» может обмениваться только теми данными, которые он «умеет» и «хочет» выдать другой системе;
- АС ВН — «потребитель» может читать любые данные, которые ему доступны (разрешены).
1. Замысел замены множества протоколов обмена одним унифицированным
При наличии множества (п) частных протоколов информационного обмена каждая /-я автоматизированная система военного назначения (АС ВН) для обеспечения обмена данными по схеме «каждый с каждым» должна обеспечить реализацию протоколов всех моделей данных (рис. 1.1).
Информационная модель обмена данными (ИМОД) реализует идею создания в дополнение к существующим п протоколам обмена нового унифицированного протокола (п+1)-го.
В такой ситуации каждой /-й АС ВН достаточно научиться работать с этим (п+1)-м протоколом (с ИМОД).
Основное требование к такому протоколу — реализация основных возможностей всех п частных протоколов (рис. 2).
Допустимы несколько вариантов обмена с использованием ИМОД:
1) передача сообщений внешними АС ВН:
• каждая внешняя АС ВН передает сообщения, созданные по своему внутреннему протоколу («не ИМОД»). Эти сообщения на приемной стороне обрабатываются адаптером, который преобразовывает сообщения в ИМОД-файлы;
• далее ИМОД-файлы почтовым транспортом передаются почтовому клиенту;
• почтовый клиент передает ИМОД-файлы на обработку специализированному приложению-диспетчеру;
Рис. 1. Существующая схема обмена данными
Рис. 2. Предлагаемая схема обмена данными
• приложение-диспетчер отправляет ИМОД-файлы в БДили какому-либо другому потребителю;
2) передача донесений от источника (АС ВН), который способен формировать УФД:
• почтовый клиент на стороне «потребителя» принимает УФД-документ и передает его приложению-диспетчеру на обработку;
• приложение-диспетчер извлекает из УФД «вставки» в формате ИМОД и отправляет их в БДили какому-либо другому потребителю;
3) почтовый клиент на стороне «потребителя» получает ИМОД-файл от почтового транспорта:
• почтовый клиент передает ИМОД-файл приложению-диспетчеру;
приложение-диспетчер отправляет ИМОД-файл в БДили какому-либо другому
потребителю.
ИМОД необходимо рассматривать как язык, с помощью которого должен организовываться обмен между АС ВН (т.е. с точки зрения той или иной АС ВН — информационный обмен с внешними системами). При этом формально ИМОД (схемы ИМОД) допускает достаточно широкое использование. Это связано с тем, что схемы ИМОД содержат в своей структуре такое множество элементов, атрибутов и правил, которое позволяет обмениваться значениями сущностей моделей всех предметных областей. В связи с изложенным возникает два основных требования к свойствам ИМОД:
1. Использование ИМОД имеет смысл для каждой пары конкретных АС ВН, обменивающихся конкретными наборами данных.
Имеется в виду, что бессмысленно «примерять» ИМОД к внутренней модели данных некоторой АС ВН безотносительно решения задачи информационного обмена с другой АС ВН.
В качестве примера можно привести условную метеорологическую АС, в которой погодные процессы описываются подробно (возможно, вплоть до движения молекул). Однако, например, ни одной другой внешней АС ВН информация в таком объеме (с такой детализацией) не нужна, а нужны текущие или прогнозируемые данные о температуре воздуха, воды, силе и направлении ветра, характере осадков и другие макропараметры, описывающие погодные условия.
В связи с этим пытаться «примерять» возможность передачи данных о молекулах с помощью ИМОД бессмысленно и даже вредно, хотя внутри рассматриваемой метеорологической АС эти данные могут носить исключительную важность.
В качестве другого примера можно привести АС ВН — потребитель данных, которая должна отображать объекты, поступающие с помощью сообщений ИМОД, на цифровой карте местности. В принципе, схема ИМОД допускает отсутствие координат у объектов обстановки, однако очевидно, что АС ВН — потребителю данных объекты без координат будут не нужны, т.к. все равно не представится возможности отобразить их на карте.
2. Кроме формального соответствия сообщений ИМОД той или иной схеме (валидности сообщений ИМОД), каждое сообщение должно содержать определенный смысл, который должен быть понятен получателю сообщения и иметь для него определенное значение.
Как и в любом другом языке, формально взятые правильные слова из словаря сложенные в предложение, соответствующее правилам этого языка, не обязательно имеют смысл.
2. Онтология предметной области «вооруженное противоборство» —
основа унификации обмена данными
Онтология — целостная структурная спецификация предметной области, ее формализованное представление, которое включает словари (или имена) терминов предметной области и логические выражения, описывающие их соотношения друг с другом. Онтология определяет целостную систему взаимоувязанных понятий предметной области «вооруженное противоборство» (рис. 3).
К основным типам и объектам этой предметной области можно отнести:
— воинские формирования (ВФ);
— вооружение, военную и специальную технику (ВВСТ), материальные средства;
— объекты инфраструктуры (ОИ);
— условия обстановки;
— личный состав;
— состояние объекта.
Примеры онтологии для объектов «Воинское формирование» и «Су-27» представлены на рис. 4 и 5 соответственно.
3. Технологии обеспечения унифицированного обмена данными
между разнородными системами
Для формализации содержания информационных сообщений, используемых в процессе информационного обмена, используется метод перевода сообщений в такой формат сооб-
Рис. 3. Онтология вооруженного противоборства
Рис. 4. Пример для объекта «Воинское формирование»
Рис. 5. Пример для объекта «Су-27»
щений ИМОД, который требуется для решения поставленной задачи при осуществлении информационного взаимодействия внутри АС, а также с внешними АС. Архитектурное представление ИМОД показано на рис. 6.
Информационная модель обмена данными
представляет собой набор стандартов, содержащих описание структуры и формата данных, передаваемых при формализованном обмене данными между элементами (подсистемами) различных систем
Модуль регламентированного формализованного обмена данными (МРФОД} обеспечивает обмен данными в локальной и глобальной сетях на основе модуля доступа к распределённым ресурсам (мдрр) с возможностями реализации механизма подлиски/ публикации, файлового обмена, а также контроля доступа абонентов к данным
Модуль доступа к рас п редел ённым ресурсам
предоставляет унифицированный программный интерфейс, позволяющий абоненту без
непосредственного использования сетевых протоколов подключиться к транспортной системе и обменяться данными о погоде с другими абонентами.
Семантическая составляющая информационного обмена
Высокоуровневый обмен данными в локальной и глобальной сетях
Низкоуровневый обмен данными
между пользователями
ИМОД, документы 1
мраюд
Сетевые протоколы
МДРР
L
TCP/IP, Ethernet,...
А
Рис. 6. Архитектура ИМОД
Технически ИМОД представляет собой набор схем (или языков в терминах W3C), определяющих состав и структуру передаваемых данных1. Все схемы составлены с помощью:
- языка определения XML-схем XML Schema 1.0 (такая реализация ИМОД здесь и далее обозначается ИМОД-XML);
- языка определения интерфейсов IDL Google Protocol Buffers 2.4 (ProtoBuf) (такая реализация ИМОД обозначается ИМОД-BIN).
Таким образом, сами передаваемые данные должны быть представлены либо в формате XML (ИМОД.XML), либо в бинарном формате, получаемом путём сериализации объектов, полученных с использованием технологии ProtoBuf (ИМОД.ВЩ).
Пример использования схемы ИМОД представленные в таблице. Представленный в таблице набор схем может быть расширен в зависимости от информационных потребностей конкретной АС.
'Информационная модель обмена данными о вооруженном противоборстве // АО«НПО «РусБИТех». URL: https://rusbitech.ru/ products/sppr/imod (дата обращения 21.08.2019).
Схемы ИМОД
Наименование схемы Описание схемы
Информационная модель обмена данными Определение глобальных (в рамках ИМОД) типов данных, элементов и атрибутов
Паспорт сообщения ИМОД Общее описание сообщения (пакета сообщения) ИМОД
Табличные данные Описание представления данных в виде произвольной таблицы
Географические данные Описание представления данных в географическом пространстве
Классификатор Описание представления классификатора (списка), каждый элемент которого определяется уникальным идентификатором
Условно-постоянные данные об объектах Описание представления значений условно-постоянных данных об объектах (характеристик объектов)
Подготовка Описание исходных данных и результатов занятий по боевой (оперативной) подготовке
План мероприятий Описание плана мероприятий, его элементов и параметров
Текущая обстановка и планы объектов Описание текущих, планируемых и прогнозируемых параметров и действий объектов и среды
Терминологический словарь Описания представления терминологических словарей
Запрос Запрос на получение недостающих данных для обеспечения информационного обмена
Переходный ключ Описание соответствия между идентификаторами объектов в различных информационных системах
Управление системой (процессом) Описание представления данных управления системой (процессом)
Форма Описание представления и оформления произвольных структурированных текстово - табличных данных
3.1. Схема «Информационная модель обмена данными»
Схема «Информационная модель обмена данными» — общая часть ИМОД содержит глобальные в рамках ИМОД типы данных и предназначена для совместного использования с различными схемами ИМОД. Типы данных, объявленные в общей части модели, могут использоваться сразу несколькими схемами ИМОД.
Величина значения параметра, используемого при информационном обмене, указывается в зависимости от типа данных, использованного в схеме, при этом необходимо различать следующие типы данных:
—числовые или другие упорядоченные (дата-время, упорядоченные перечисления); — неупорядоченные.
Типы данных делятся на упорядоченные и неупорядоченные по принципу сравнимости их значений. То есть к значениям упорядоченных типов можно применять операторы сравнения (больше, меньше и т.д.). К значениям неупорядоченных типов можно применять только операторы равенства или вхождения в множество.
3.2. Схема «Паспорт сообщения ИМОД»
Схема «Паспорт сообщения ИМОД» представляет собой формализованный язык описания служебной информации о сообщениях ИМОД. Использование данной схемы предполагается для определения заголовков сообщений (пакетов данных) на языке ИМОД, передаваемых между абонентами при формализованном информационном обмене.
Схема «Паспорт сообщения ИМОД» определяет состав и структуру следующих основных данных:
— абонент — отправитель сообщения (пакета);
— абоненты — получатели сообщения (пакета);
— степени срочности, секретности сообщения (пакета);
— состав сообщения (пакета);
— другая служебная информация.
3.3. Схема «Табличные данные»
Схема «Табличные данные», представляет собой формализованный язык описания произвольной табличной информации. Использование данной схемы предполагается для описания данных, структурированных в виде таблицы и не подходящих под структуру других схем ИМОД. Например, табличный результат решения задачи определения количественно-качественного соотношения сил противостоящих группировок.
3.4. Схема «Географические данные»
Схема «Географические данные» представляет собой формализованный язык описания произвольной географической информации. Использование данной схемы предполагается для описания географических структурированных данных, не подходящих под структуру других схем ИМОД. Примером использования схемы может служить некоторая обобщенная зона обнаружения системы ПВО группировки войск (сил), полученная в результате решения информационно-расчетной задачи.
Схема «Географические данные» определяет состав и структуру следующих основных данных:
—точка в географическом пространстве;
— фигура в географическом пространстве;
— перемещение объекта в географическом пространстве.
3.5. Схема «Классификатор»
Схема «Классификатор» представляет собой формализованный язык описания линейных, иерархических и фасетных структур (списков или классификаторов). Использование данной схемы предполагается для описания любых классификаторов (списков), каждый эле-
мент которых определяется уникальным идентификатором и имеет некоторое наименование. Примером использования схемы может служить классификатор стран мира и др.
Схема «Классификатор» определяет состав и структуру следующих основных данных:
— информационный элемент с уникальным идентификатором и наименованием;
— иерархическая или фасетная взаимосвязь информационных элементов.
3.6. Схема «Условно-постоянные данные об объектах»
Схема «Условно-постоянные данные об объектах» представляет собой формализованный язык описания значений условно — постоянных параметров тех или иных объектов. Использование данной схемы предполагается для описания не привязанных к конкретному времени и пространству значений параметров объектов. Примером использования схемы может служить массив значений тактико — технических характеристик образцов вооружения и военной техники.
Схема «Условно-постоянные данные об объектах» определяет состав и структуру следующих основных данных:
— идентификатор описываемого объекта;
— идентификатор параметра (характеристики);
—типизированное значение параметра (характеристики) объекта.
3.7. Схема «Подготовка»
Схема «Подготовка» представляет собой формализованный язык описания исходных данных для проведения занятий по боевой (оперативной) подготовке и результатов, достигнутых в ходе проведения занятий.
Использование схемы предполагается для организации информационного взаимодействия технических средств обучения, предназначенных непосредственно для проведения занятий по боевой (оперативной) подготовке (полигонное оборудование, тренажеры, компьютерные классы и т.д.) и средств автоматизации планирования и контроля боевой (оперативной) подготовки.
Примером использования схемы «Подготовка» может послужить передача на тренажер списка личного состава, темы и сценария занятия в качестве исходных данных для его проведения, а затем — получение результатов занятия: списка фактически участвовавших в нем лиц, полученных каждым из них и формированием в целом оценок, а также значений достигнутых параметров при выполнении упражнений, совершенных ошибок и т.д.
Схема «Подготовка» определяет состав и структуру следующих данных:
— участники занятий (обучаемые, обучающие);
— планируемые занятия и их параметры;
— проведенные занятия, их параметры и достигнутые результаты.
3.8. Схема «План мероприятий»
Схема «Планы мероприятий» представляет собой формализованный язык описания планов проведения мероприятий.
Использование схемы предполагается для описания различных планов мероприятий, подразделяющихся на этапы и периоды, взаимосвязанных между собой. Примером использования
схемы могут быть планы боевой подготовки воинских формирований на различных уровнях, когда план подготовки объединения содержит мероприятия, которые детализируются в планах подготовки соединений, при этом у них взаимосвязаны мероприятия, этапы и периоды.
Схема «Планы мероприятий» определяет состав и структуру следующих данных:
— планы с этапами и периодами проведения мероприятий;
— взаимосвязи между элементами разных планов.
В составе элемента План можно выделить четыре основные части:
— заголовок сообщения ИМОД о планах мероприятий;
— сведения об удаляемых элементах плана мероприятий;
— блок описания плана мероприятий;
— блок организации отношений между элементами разных планов.
3.9. Схема «Текущая обстановка и планы объектов»
Схема «Текущая обстановка и планы объектов» представляет собой формализованный язык описания вооруженного противоборства во всех сферах его протекания (космической, воздушной, наземной, надводной, подводной).
Основное назначение схемы — применение ее в качестве стандартизированного и унифицированного протокола при организации автоматического «машинного» обмена данными о текущей складывающейся обстановке в АС, как при подготовке операций (боевых действий), так и при управлении войсками (силами) в ходе их ведения.
Схема «Текущая обстановка и планы объектов» обладает следующими свойствами:
— возможностью описания различных физических сред и областей деятельности для обеспечения совместных (межвидовых) операций сухопутных, морских, воздушных и космических сил;
— функциональной полнотой и достаточностью, то есть иметь минимальную избыточность для описания основных сущностей вооруженного противоборства;
— возможностью расширения для обеспечения информационных потребностей АС.
Схема «Текущая обстановка и планы объектов» определяет состав и структуру следующих основных данных:
— объекты обстановки и значения их текущих (в рамках заданного момента времени) параметров, а также текущее поведение (ход выполнения боевых задач);
— параметры текущего состояния среды (метеорологического, радиоэлектронного, акустического, радиационного, химического, биологического и др.);
— планы боевых действий, боевые задачи объектов обстановки (прогнозируемое состояние и поведение), прогнозируемое состояние среды (для будущих моментов времени), а также условия их перехода в подобное состояние (к подобному поведению).
В составе элемента можно выделить четыре основные части:
— заголовок сообщения ИМОД о текущей обстановке;
— служебные данные — объявление значений по умолчанию;
— блок объявлений элементов, используемых многократно;
— данные временных срезов, содержащие сведения об объектах, их текущих параметрах, действиях (текущих и планируемых) и взаимосвязях.
3.10. Схема «Терминологический словарь»
Схема «Терминологический словарь» представляет собой формализованный язык описания исходных данных для описания терминологических словарей.
Схема определяет состав и структуру следующих данных:
— разделы словаря;
— термины и их определения;
— отношения между терминами.
В составе элемента можно выделить две части:
— заголовок сообщения ИМОД о терминологическом словаре;
— описание терминологического словаря.
3.11. Схема «Запрос»
Схема «Запрос» представляет собой формализованный язык запросов на уточнение данных, полученных с помощью других схем ИМОД. Использование данной схемы предполагается в ситуациях, когда получившая некоторое сообщение ИМОД система не имеет достаточных для ее работы данных о ряде объектов (сущностей), присутствующих в этом сообщении.
Схема «Запрос» определяет состав и структуру следующих основных данных:
— идентификатор сущности (объекта), данные по которому необходимо уточнить;
— набор данных, который необходимо уточнить (получить) по указанной сущности (объекту).
3.12. Схема «Переходный ключ»
Схема «Переходный ключ» представляет собой формализованный язык описания данных о соответствии сущностей (объектов) в различных списках (классификаторах) различных систем кодирования.
Использование данной схемы предполагается в технологических целях для установления соответствия одинаковых сущностей предметной области в различных информационных системах.
Примером использования схемы может служить таблица соответствия между образцами вооружения и военной техники в различных классификаторах.
Схема «Переходный ключ» определяет состав и структуру следующих основных данных:
— идентификатор сущности (объекта) в одной системе кодирования;
— идентификатор соответствующей сущности (объекта) в другой системе кодирования;
— другая служебная информация о соответствии сущностей (объектов).
3.13. Схема «Управление системой»
Схема «Управление системой» представляет собой формализованный язык описания параметров работы системы на определенный момент времени.
Использование схемы предполагается в ситуациях, когда необходимо передать системе параметры ее работы или получить текущие параметры работы системы.
Схема «Управление системой» определяет состав и структуру следующих данных:
— срез астрономического времени;
— набор данных, описывающих состояние и параметры работы системы.
В составе элемента можно выделить две части:
— заголовок сообщения ИМОД управления системой;
— описание параметров и состояния системы.
3.14. Схема «Форма»
Схема «Форма» представляет собой формализованный язык описания произвольных структурированных текстово-табличных данных, организованных в виде формы (видеоформы или формы документа).
Схема определяет состав и структуру следующих данных:
— стиль оформления содержимого формы;
— элементы компоновки формы;
— блоки с содержимым (данные в виде текста или таблицы);
— отношения между элементами формы.
В составе элемента можно выделить две части:
— заголовок сообщения ИМОД управления системой;
— описание формы.
Представленные схемы ИМОД должны использоваться совместно с машиночитаемыми словарями (рубрикаторами).
3.15. Методы и способы выделения, представления содержания
информационных сообщений
Для обеспечения информационной совместимости АС с другими АСУ ВН целесообразно использовать метод перевода информации в машиночитаемый формат ИМОД.
Кодирование информации в формат ИМОД осуществляется посредством замены языковых конструкций естественного языка, описывающего предметную область АС, на конструкции языка XML или бинарные коды. Для сохранения семантических единиц речи естественного языка, определяется набор правил в строгом соответствии с которыми, должны формироваться XML-документы или бинарные сообщения.
Существующий механизм XSD-схем позволяет определять правила, которым должен подчиняться создаваемый XML-документ.
Таким образом, основной набор правил формализации информации в формате ИМОД для образования групп слов, объединенных в смысловом отношении, в составе сообщений представляется в виде набора XSD-схем.
XSD-схемы позволяют решать следующие задачи:
— определить словарь элементов (атрибутов), применяемых для формирования XML-документа;
— проверить наличие в документе объявленных элементов (атрибутов);
— установить отношения подчиненности между элементами;
— определить состояние и содержание элементов (атрибутов);
— задать требуемые типы данных;
— установить значения по умолчанию, фиксированные значения и др.
После проверки XML-документа на соответствие XSD-схеме читающая программа может создать модель данных документа, которая включает:
— словарь (названия элементов и атрибутов);
— модель содержания (отношения между элементами и атрибутами и их структура);
—типы данных.
Для описания структуры XSD-схемы включают в свой состав определенные разработчиками типы данных.
При определении типов данных должны выполняться установленные в стандарте языка описания данных правила.
Простой тип данных не может содержать внутри себя какие-либо другие элементы. Он может быть одним из базовых типов, которые включаются в определение XSD-схемы, или типом, определенным пользователем самостоятельно.
Перечисляемый тип (перечисление) — это тип данных, где множество значений представляет собой ограниченный список идентификаторов.
Массивы значений представляют собой множество значений одного конкретного типа.
Сложный тип данных определяется в терминах других типов данных.
В схемах ИМОД предусмотрены расширенные возможности по указанию значений тех или иных передаваемых при обмене параметров. Для этого значения параметров указываются не только в виде точных величин, но и в виде множеств с диапазоном значений.
Для указания значений параметров в виде множества необходимо указать оператор, применяемый к величине (равно, неравно, больше, меньше и т.д.), а в случае диапазона, указать его границы.
В общем случае, при обмене данными между различными АС могут передаваться параметры, описание которых в существующих XSD-схемах не предусмотрено в виду их крайне редкого использования.
В связи с этим, для передачи всех остальных данных, явно не предусмотренных структурой ИМОД, введены специальные возможности, позволяющие пользователям:
— определять дополнительные параметры передаваемых сообщений;
— создавать собственную реализацию абстрактных сложных типов.
Таким образом, предусмотрена возможность расширения и дополнения передаваемых XML-сообщений нетипичными (дополнительными) параметрами (extraParams).
В зависимости от сценария информационного взаимодействия и задачи, решаемой в процессе информационного взаимодействия компонентов БАСУ могут быть определены следующие способы представления сообщений в формате ИМОД:
—XML-сообщения ИМОД;
— бинарные сообщения ИМОД.
XML-сообщения ИМОД представляются в текстовом формате. Корректность формирования (валидность) такого сообщения проверяется с помощью соответствующей XSD-схемы ИМОД.
Фрагмент сообщения ИМОД в формате XML для схемы «Классификатор» представлен
ниже:
<?xml version="1.0" encoding="UTF-8"?>
<cls: imod
xmlns: cls="imod: cls"
xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance">
<id>02b178b7-ae25-4eff-871c-35db871f76e4</id>
<xsdVersion>3.2.1</xsdVersion>
<name>Пример для схемы ИМОД.Классификатор</name> <classifier>
<id>cc502708-313b-45d8-84a7-3cdefe0b8112</id> <name>Классификатор BBT</name> <extraField>
<name>Автомобильная и бронетанковая техника</name> <extraFieldValue>
<extraFieldRef>1389c8a6-91ba-45f2-9d59-f16a87fc97ce</extraFieldRef>
<value>0</value>
</extraFieldValue>
<name>Боевые машины десанта</name>
<parentPositionRef>cff899fd-69d7-4d8d-8c42-5c97091452e0</parentPositionRef> <extraFieldValue>
<extraFieldRef>1389c8a6-91ba-45f2-9d59-f16a87fc97ce</extraFieldRef>
<value>0</value>
</extraFieldValue>
</position>
<position>
<id>e7e4f3de-f585-4c31-8922-19c50cab7739</id>
<code>818099</code>
<name>БМД-2</name>
<parentPositionRef>22ddb44a-2742-45f8-b311-775bda1d4a4a</parentPositionRef>
<extraFieldValue>
</position>
</classifier>
</cls: imod>
Выбор технологии XML обусловливается поддержкой данной технологии широким спектром как программных, так и аппаратных средств (что немаловажно для АС, так как ряд систем реализуется с использованием аппаратно-программных платформ, отличных от традиционных — Intel x86, операционных систем семейства Windows или Linux).
Бинарные сообщения ИМОД представляются в формате Google Protocol Buffers и сери-ализуются в соответствующие программные классы.
В отличие от XML при использовании бинарного формата необходимость в специальной проверке правильности структуры передаваемых данных отсутствует.
Корректность данных проверяется в процессе сериализации экземпляров программных классов.
Фрагмент proto-файла ИМОД для схемы «Классификатор» представлен ниже.
syntax = "proto3"; package silo.cls;
import "google/protobuf/timestamp.proto";
/**
* Запрос общей информации о классификаторе.
*
* Request.request_object == REQUEST_CLASSIFIER
*/
message RequestClassifier {bytes classifier_id =1; // Идентификатор классификатора (UUID, 16 байт).
bool with_info = 2; // С атрибутивными сведениями.
bool with_structure = 3; // Со структурой.
bool with_extra = 4; // С дополнительными признаками.
bool with_codification_block = 5; //С блоками кодификации. }
/**
* Перечисление типов групп.
*/
enum ESectionType { PART = 0; // Раздел/Часть. GROUP = 1; // Группа.
CLASSIFICATION_GROUP = 2; // Классификационная группировка.
FACET = 3; // Фасет. }
/**
* Перечисление типов признаков
*/
enum EExtraType {
EXTRA_SIMPLE = 0; // Дополнительный признак, принимающий простые значения. EXTRA_FACET = 1; // Дополнительный признак, являющийся фасетом. EXTRA_GROUP = 2; // Группировка дополнительных признаков.
EXTRA_EXTERN = 3; // Дополнительным признаком является фасет из другого классификатора или сам другой классификатор. }
* Основная информация о классификаторе.
*/
message Classifier {
bytes id = 1; //Идентификатор классификатора (UUID, 16 байт). string name = 2; // Полное наименование классификатора.
uint32 access_type = 3; // Тип доступа к классификатору. Является битовой маской. Допускается сочетание следующих // значений: 0x00 — доступ запрещён; 0х01 — чтение (0001); 0х02 — редактирование (0010); 0х04 — удаление (0100).
bool delete_mark = 4; // Пометка на удаление.
uint32 revisio = 5; // Номер текущей ревизии классификатора.
google.protobuf.Timestamp updated_at = 6; // Дата (официальная) последнего изменения
классификатора.
}
string code_pattern = 6;// Формула структуры идентификационного кода.
ECodeGeneration code_generation = 7; // Способ генерации кода позиций дополнительного признака.
bytes external_classifier_id = 8; // Идентификатор внешнего классификатора (UUID, 16
байт).
bytes external_section_id = 9; // Идентификатор секции внешнего классификатора (UUID, 16 байт).
repeated LinkedExtraField linked_extra_fields = 10; // Дополнительные признаки, которыми обладает текущий дополнительный признак.
bool delete_mark = 11; // Пометка на удаление.
string extra_format = 12; // Формат, которому должны соответствовать значения дополнительного признака.
}
/**
Важным достоинством бинарного формата представления является обеспечение обратной совместимости (в случае добавления новых полей в новой версии при разборе данных по старой версии эти поля будут просто игнорироваться).
Такой подход выгодно отличает данную технологию от традиционного подхода, при котором для передачи бинарных данных формируются кодограммы (или дейтаграммы), в которых указывается назначение каждого бита.
Обе реализации ИМОД взаимосвязаны между собой. Базовый набор схем ИМОД представляется набором XSD-схем. Данное представление является более наглядным для пользователя и удобным для редактирования. Proto-файлы получаются путем автоматической генерации, разработанных XSD-схем. При этом обеспечивается полное соответствие наименований (идентификаторов) элементов в формате XML бинарному формату. Реализованные на языке C++ соответствующие приложения позволят осуществлять автоматическое преобразование сообщений из формата XML в бинарный формат и обратно (рис. 7).
Заключение
Рассмотрев актуальность проблемы обеспечения взаимодействия разнородных систем управления, следует отметить, что ее решение становится приоритетным направлением в реализации концепции «ведения боевых действий с использованием единого информационно-коммуникационного пространства».
Рис. 7. Автоматическая генерация сообщений ИМОД
С технической точки зрения необходимо совершенствовать всевозможные технологии организации взаимодействия и совместимости автоматизированных систем управления, стремиться к реализации «бесшовного» взаимодействия на основе использования в АС единого протокола обмена данными, как между компонентами АС, так и с внешними АС ВН. В качестве такого протокола предлагается использовать информационную модель обмена данными о вооруженном противоборстве.
Предложен подход, позволяющий автоматизировать процесс межсистемной интеграции. Решена проблема исключения «горячего программирования» при внесении минимальных изменений в структуру или содержание информационных пакетов за счет синтеза XML-пакетов на основе XML-шаблонов. XML обеспечивает универсальный формат информационных сообщений, а XSD — строго определенную семантику. Организация взаимодействия с основной информационной системой через служебные таблицы базы данных дает возможность асинхронного выполнения заданий информационного обмена с внешними АС ВН. Предложенный подход позволяет разработчикам реализовывать требуемый функционал для взаимодействия в отдельном модуле интеграции, функционирующем на сервере базы данных и/или приложений, и избавляет от необходимости дорабатывать основную информационную систему для нужд интеграции. Важным плюсом разработанного подхода является автономность и кроссплатформенность разрабатываемых на его основе программных средств.
Опыт разработки и эксплуатации ИМОД показал, что реализованный подход без внесения существенных доработок в программное обеспечение АС ВН может быть применен при решении задач межсистемной интеграции в сфере вооруженного противоборства.
Литература
1. Акаткин Ю., Дрожжинов В., Конявский В. Стандарты моделей данных для обмена информацией как инструмент импортозамещения в стратегических информационных систе-
мах // Технологии информационного общества в науке, образовании и культуре: сборник научных статей XVII Всероссийской объединенной конференции «Интернет и современное общество» (IMS-2014) (Санкт-Петербург, 19-20 ноября 2014 г.). СПб.: Изд-во Санкт-Петербургского национального исследовательского университета информационных технологий, механики и оптики, 2014. С.219-223.
2. Башлыкова А. А., Олейников А. Я. Интероперабельность и информационное противоборство в военной сфере // Журнал радиоэлектроники. 2016. № 12. C. 1-14. URL: http://jre. cplire.ru/jre/dec16/14/text.pdf (дата обращения: 21.08.2019).
3. Безель Я. В. Развитие и совершенствование автоматизированных систем управления воздушно-космической обороны и испытательной базы межвидового испытательного полигона Минобороны России // Вестник Концерна ПВО «Алмаз — Антей». 2015. № 2. С. 12-15.
4. Белорусов А. И. Интеграция информационных систем на основе стандартов XML и WEB-сервисов в сфере закупок // Молодой учёный. 2015. № 11 (91). С. 9-15.
5. Бобков Ю. Я., Тютюнников Н. Н. Концептуальные основы построения АСУ сухопутными войсками ВС РФ. М.: Палеотип, 2014. 92 с.
6. Каменщиков А.А., Олейников А. Я., Чусов И. И., Широбокова Т.Д. Проблема интеропе-рабельности в информационных системах военного назначения. // Журнал радиоэлектроники. 2016. № 11. 1-16. URL: http://jre.cplire.ru/jre/nov16/8/text.pdf (дата обращения: 21.08.2019).
7. Coolahan J.E., Morse K. L., Saunders R., Lutz R. R., Riggs W. C. Live-Virtual-Constructive (LVC) Architecture Roadmap Implementation Workshop. Proc. of the 2010 Spring Simulation Interoperability Workshop, Orlando, FL., Apr.15. 2010. SISO, 2010. Pp. 71-74.
8. Копытко В.К., Шептура В. Н., Проблемы построения единого информационного пространства Вооруженных Сил Российской Федерации и возможные пути их решения // Военная мысль. 2011. № 10. С. 16-26. URL: http://www.avnrf.ru/index.php/publikatsii-otdelenijavn/nauchnykh-otdelenij/voennogo-iskusstva/204-problemy-postroeniya-edinogoinformatsionnogo-prostranstva-voomzhennykh-sil-rossijskoj-federatsii-ivozmozhnye-puti-ikh-resheniya?limitstart&showall=1 (дата обращения 21.08.2019)
9. Панков А. В., Шевченко С. В. Обоснование роли и формирование концептуальной модели системы интеллектуальной обработки информации в едином информационном пространстве ВС РФ// Известия СПбГЭТУ «ЛЭТИ». 2018. № 1. С. 38-43.
10. Подберезкин А. И., Мунтян М. А., Харкевич М. В., Ручкин Г. Р., Салюков Д. О., Родионов О. Е., Малов А. Ю., Цырендоржиев С. Р., Жуков А. В. Долгосрочные сценарии развития стратегической обстановки, войн и военных конфликтов в XXI веке: аналитический доклад / Моск. гос. ин-т междунар. отношений (ун-т) МИД России, Центр военно-политических исследований. М.: МГИМО-Университет, 2014. 175 с.
11.Свидетельство о государственной регистрации программ для ЭВМ № 2011618877 Информационная модель обмена данными о вооруженном противоборстве (ИМОД) / Ляпин В. Р., Бодрин А. В., Зимин В. Н., Игнатьев С. А., Королёв В. В., Кравченко М. В., Марчук В. А., Никитин А. С., Никодимов А. В., Пустовой В. И., Финошкин И. Д., Яночкин И. Е.; правообладатель ООО «Научно — производственное объединение «Русские базовые информационные технологии»; заявл. 20.09.11; опубл. 15.11.11.
ON UNIFICATION OF DATA EXCHANGE BETWEEN HETEROGENEOUS MEANS AND SYSTEMS IN A SINGLE INFORMATION SPACE
MAKSIM V. KRAVCHENKO,
Senior systems analyst, Joint Stock Company "Research Production Association Russian Basic Information Technologies", Moscow, Russia, m.kravchenko@rusbitech.ru
ALEKSANDR S. NIKITIN,
PhD, Docent, Head of department, Joint Stock Company
"Research Production Association Russian Basic Information Technologies",
Tver, Russia, a.nikitin@rusbitech.ru
SERGEY I. SPIRIDONOV,
Research officer, Joint Stock Company "Research Production Association Russian Basic Information Technologies", Tver, Russia, s.spiridonov@rusbitech.ru
ABSTRACT
It was established that when equipping the organs and command posts of the Armed Forces of the Russian Federation with complex automation means their action applies to all periods of activity, through automation of control is achieved during the daily activities of troops, which ensures the full realization of the capabilities of command posts for command and control of troops. At the same time, a unified information space is formed and used on the basis of a unified automated data collection system, unified databases, unified protocols of functional interaction, which ensures the integration of all information resources. In the article the technology of providing unification of data exchange between heterogeneous automated systems of military purpose with the use of information model of data exchange on armed confrontation is offered. The information model for the exchange of data on armed conflict is a set of standards that describe the structure and format of data transmitted in the formalized exchange of data between automated military systems. At the same time, it is necessary to pay attention to the fact that the information model of data exchange in any case does not replace the internal models of data of automated systems, or information models of subject areas related to the military sphere of activity. The information model of data exchange is considered only as a language (set of languages), with the help of which the exchange between automated systems is organized (i.e. from the point of view of one or another automated system - information exchange with external systems).
Keywords: automated system; single information space; information model of data exchange; information exchange; Protocol of exchange; data structure.
REFERENCES
1. Akatkin Yu., Drozhzhinov V., Konyavskiy V. Re-Inventing Interoperability of E-Government Data Sharing. Tekhnologiiinformatsion-nogo obshchestva v nauke, obrazovanii i kul'ture: sbornik nauchnykh statey XVII Vserossiyskoy ob'edinennoy konferentsii "Internet isovremennoe obshchestvo" [Information society technologies in science, education and culture: collection of scientific articles
of the XVII all-Russian joint conference "Internet and modern society" (IMS-2014), Saint Petersburg, November 19-20, 2014]. St. Petersburg: ITMO University, 2014. Pp. 219-223. (In Rus)
2. Bashlykova A. A., Oleinikov A. Ya. Interoperability and information confrontation in military field. Zhurnal radioelektroniki [JOURNAL OF RADIO ELECTRONICS]. 2016. No. 12. URL: http://jre.cplire.ru/jre/dec16/14/text.pdf (date of access 21.08.2009) (In Rus)
3. Bezel Y. V. Development and improvement of automated control systems of aerospace defence and testing facilities interspecific test site Russian Defence Ministry. Vestnik Kontserna PVO "Almaz - Antey" [Bulletin of the Almaz - Antey air defense Concern]. 2015. No. 2. Pp. 12-15. (In Rus)
4. Belorusov A. I. Integration of information systems based on XML standards and WEB services in the field of procurement. Young Scientist. 2015. No. 11 (91). Pp. 9-14. (In Rus)
5. Bobkov Yu. Ya., Tyutyunnikov N. N. Kontseptual'nye osnovypostroeniya ASUsukhoputnymi voyskami VS RF[Conceptual basis for building an automated control system by the land forces of the armed forces of the Russian Federation]. Moscow: Paleotip, 2014. 92 p. (In Rus)
6. Kamenschikov A. A., Oleinikov A. Ya., Chusov I. I., Shirobokova T. D. Problema interoperabel'nosti v informatsionnykh sistemakh voennogo naznacheniya. Interoperability problem in defence information systems. Zhurnal radioelektroniki [Journal of radio electronics]. 2016. No. 11. URL: http://jre.clire.ru (date of access 21.08.2009) (In Rus)
7. Coolahan J. E., Morse K. L., Saunders R., Lutz R. R., Riggs W. C. Live-Virtual-Constructive (LVC) Architecture Roadmap Implementation Workshop. Proc. of the 2010 Spring Simulation Interoperability Workshop, Orlando, FL., Apr.15. 2010. SISO, 2010. Pp. 71-74.
8. Kopytko V. K., Sheptura V. N. Problems of building a unified information space of the Armed Forces of the Russian Federation and possible ways to solve them. URL: http://www.avnrf.ru/index.php/publikatsii-otdelenijavn/nauchnykh-otdelenij/ voennogo-iskusstva/204-problemy-postroeniya-edinogoinformatsionnogo-prostranstva-vooruzhennykh-sil-rossijskoj-federatsii-ivozmozhnye-puti-ikh-resheniya?limitstart&showall=1 (date of access 21.08.2009) (In Rus).
9. Pankov A. V., Shevchenko S. V. Role validation and intellectual information processing system in the unified informational space of the russian armed forces concept model formation. Proceedings of Saint Petersburg Electrotechnical University. 2018. No. 1. Pp. 38-43.
10. Podberezkin A. I., Muntyan M. A., Harkevich M. V., Ruchkin G. R., Salyukov D. O., Rodionov O. E., Malov A. Yu., Tsyrendorzhiev S. R., Zhukov A. V. Dolgosrochnye stsenarii razvitiya strategicheskoy obstanovki, voyn i voennykh konfliktov v XXI veke: analiticheskiy doklad [Long-Term scenarios for the development of the strategic situation, wars and military conflicts in the XXI century: analytical report]. Moscow: MGIMO-University, 2014. 175 p. (In Rus)
11. Certificate of state registration of computer programs No. 2011618877 Informatsionnaya model' obmena dannymi o vooruzhen-nom protivoborstve (IMOD) [Information model of data exchange on armed conflict (IMOD)] / Lyapin V. R., Bodrin A. V., Zimin V. N., Ignatiev S. A., Korolev V. V., Kravchenko M. V., Marchuk V. A., Nikitin A. S., Nikodimov A. V., Pustovoy V. I., Finoshkin I. D., Yanoch-kin I. E. Declared 20.09.11; Publ. 15.11.11. (In Rus)
