gasu.gov.ru – ГАСУ Управление Обеспечение информационного взаимодействия автоматизированных систем военного назначения с использованием унифицированного сервиса взаимодействия
Полковник запаса И. Н. А ХМАДИШИН
В. В. Б АРАНЮК, кандидат технических наук
Рассмотрены ключевые проблемные вопросы обеспечения информационного взаимодействия автоматизированных систем. Представлены предложения по формированию унифицированного сервиса взаимодействия, позволяющего обеспечить обмен формализованной информацией.
Автоматизированные системы военного назначения, информационное взаимодействие, информация взаимообмена, унифицированный сервис взаимодействия.
The paper examines the key problem issues of supporting information interaction of automated systems. It gives proposals as to the formation of unified interaction service that would make for formalized information exchange.
Military-purpose automated systems, information interaction, mutual exchange information, unified interaction service.
ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОГО ВЗАИМОДЕЙСТВИЯ АС ВН С ИСПОЛЬЗОВАНИЕМ УНИФИЦИРОВАННОГО СЕРВИСА ВЗАИМОДЕЙСТВИЯ
В НАСТОЯЩЕЕ время в Вооруженных Силах Российской Федерации находятся в эксплуатации большое количество различных автоматизированных систем военного назначения (АС ВН) и комплексов средств автоматизации (КС А), размещенных в органах военного управления и на пунктах управления видов и родов войск различных уровней управления.
Значительная часть этих систем и комплексов разработана в 70—80-е годы прошлого века на разной технической, программной и информационной основе, и их модернизация либо невозможна, либо чересчур затратна, либо нецелесообразна. В основном эти АС ВН и КСА предназначены для решения различных задач управления войсками (силами) и оружием и практически информационно не взаимосвязаны. Тем не менее в данных автоматизированных системах накоплен достаточно большой объем информации, связанной со спецификой решаемых задач.
В основном необходимость обеспечения информационного взаимодействия АС ВН предусматривалась соответствующими требованиями тактико-технических заданий. Однако при их создании технические и организационные решения по взаимодействию оформлялись, как правило, в виде протоколов информационно-технического взаимодействия (ИТВ). На этапе приемки работ взаимодействие проверялось на опытных образцах или стендах. При этом взаимообмен осуществлялся условно-реальной информацией ограниченного состава.
В дальнейшем, после принятия АС ВН на снабжение и развертывания соответствующих средств автоматизации на пунктах управления, вопросы взаимодействия, как правило, уже не отрабатывались по целому ряду причин, среди которых можно выделить следующие:
• отсутствие нормативной документации, регламентирующей дей-
ствия обслуживающего персонала по обеспечению взаимодействия различных АС ВН;
• отсутствие технической возможности расширения состава объектов взаимодействия;
• отсутствие подготовленного обслуживающего персонала, способного обеспечить информационно-техническое взаимодействие с вводимыми в эксплуатацию новыми АС ВН.
В случае возникновения острой необходимости осуществления такого взаимообмена на пункты управления вызывались представители предприятий-разработчиков соответствующих АС ВН и КСА, которые за достаточно короткое время настраивали свои системы и комплексы для решения конкретных задач взаимодействия.
Несмотря на постоянное развитие информационных технологий, проблема обеспечения информационно-технического взаимодействия автоматизированных систем военного назначения в настоящее время все еще остается актуальной.
Проблема обеспечения комплексного информационно-технического взаимодействия автоматизированных систем для решения совместных задач неоднократно обсуждалась. Для ее разрешения предлагались различные решения, сводившиеся, как правило, к попытке разработки различного рода систем частных протоколов ИТВ. Единой унифицированной системы протоколов информационно-технического взаимодействия, охватывающих все АС ВН, до настоящего времени не создано.
Это обусловливается тем, что для разработки протокола информационно-технического взаимодействия необходимо определить состав информации взаимообмена, формат ее представления, регламент взаимодействия, а также решить ряд организационно-технических вопросов. Наибольшую сложность при этом вызывает обмен формализованной информацией, представленной с использованием классификаторов и справочников, так как это влечет необходимость их «выравнивания» во взаимодействующих системах.
Еще одним проблемным вопросом является неготовность некоторых главных конструкторов АС ВН к участию в совместной разработке протоколов ИТВ или их завышенные финансовые требования. Кроме того, необходимо учитывать, что в некоторых АС ВН невозможно реализовать новые протоколы ИТВ в связи с распадом коллективов разработчиков.
Все это настоятельно диктует необходимость поиска новых путей, методов и способов обеспечения информационного взаимодействия АС ВН с учетом их многообразия и сложности модернизации.
В последнее время широкое распространение получила технология обеспечения взаимодействия, основанная на предоставлении данных через сервисы. В Российской Федерации создана и успешно функционирует система межведомственного электронного взаимодействия (СМЭВ), которая позволяет федеральным, региональным и местным органам власти, кредитным организациям (банкам), внебюджетным фондам, и прочим участникам СМЭВ обмениваться данными, необходимыми для оказания государственных услуг гражданам и организациям, в электронном виде1.
Система межведомственного электронного взаимодействия состоит из
сети защищенных каналов связи между узлами, расположенными в центрах обработки данных Ростелекома. Участники СМЭВ являются поставщиками и потребителями сведений различного характера, предоставляемых через систему.
Сервисориентированная архитектура СМЭВ предполагает, что поставщик сведений (им может выступать как федеральный орган власти, так и регион) выводит через свою систему в общую шину некий электронный сервис, который при правильном запросе сведений корректно их выдает. А потребитель сведений (также регион или федеральный орган) через свою систему в шину интегрирует адаптер, который умеет правильно запрашивать сведения и получать ответ.
Создание и внедрение СМЭВ существенно упростило и ускорило документооборот в сфере оказания государственных услуг. Однако следует отметить, что эта система нацелена на обмен неформализованными электронными сведениями и документами. Последующая обработка этой информации после ее получения производится человеком.
по взаимодействию оформлялись, как правило, в виде протоколов информационно-технического взаимодействия. Взаимообмен осуществлялся условно-реальной информацией ограниченного состава.
В то же время существует объективная необходимость обмена формализованной информацией, предназначенной для использования в специальном программном обеспечении при решении различных задач.
В составе выходной информации АС ВН обычно имеется достаточно большое количество неформализованных документов, содержащих различного рода сведения о численности, составе, наличии, укомплектованности и других характеристиках, представленных, как правило, в табличном виде. Эти сведения в основном представляют собой агрегированную информацию по конкретным аспектам деятельности, сформированную путем сбора исходных данных от объектов-источников и обработанную по определенным правилам в АС ВН.
Такие документы в своем большинстве формируются пользователями или обслуживающим персоналом автоматизированной системы в процессе ее эксплуатации. Как показывает практика, именно эта агрегированная информация и составляет основную массу сведений, интересующих взаимодействующие системы и включаемых в протоколы ИТВ.
Таким образом, для обеспечения информационного взаимодействия без использования протоколов ИТВ необходимо сформировать унифицированный сервис, позволяющий выделять формализованные сведения
из неформализованных документов, формируемых системами-источниками, и передавать их системам-потребителям в унифицированном виде.
В этом случае вместо реализации протоколов ИТВ потребуется обеспечить взаимодействие системы-потребителя не со всеми системами-источниками, а только с указанным унифицированным сервисом.
Формирование унифицированного сервиса взаимодействия потребует решения ряда сложных задач, которые можно разделить на:
Решение технических задач связано с программной реализацией сервиса и его техническим взаимодействием с системами-источниками и системами-потребителями.
Основные функции, которые должны быть реализованы в сервисе:
• формирование коллекций входных документов с привязкой к источнику, их типизация и систематизация;
• выделение табличных данных во входных документах;
• семантическое описание выделенных табличных данных;
Для обеспечения информационного взаимодействия без использования протоколов ИТВ необходимо сформировать унифицированный сервис, позволяющий выделять формализованные сведения из неформализованных документов, формируемых системами-
источниками, и передавать их системам-потребителям в унифицированном виде. В этом случае вместо реализации протоколов ИТВ потребуется обеспечить взаимодействие системы-потребителя не со всеми системами-источниками, а только с указанным унифицированным сервисом.
• преобразование выделенных табличных данных в унифицированный выходной формат с использованием стандартизованных метаданных;
• передача преобразованных данных в унифицированном формате в системы-потребители.
Решение информационных задач связано с выделением необходимой информации в исходных документах и ее преобразованием в унифицированный вид. Настройка сервиса на конкретные входные документы должна осуществляться специалистами, обладающими знаниями в соответствующей предметной области. Поэтому целесообразно эту настройку осуществлять на стороне системы-источника с привлечением должностных лиц органов военного управления, применяющих данную систему в своей повседневной деятельности.
При вводе сервиса в эксплуатацию основной фокус переместится на решение организационных задач, связанных с определением порядка и правил формирования документов в системах-источниках для их передачи и обработки в сервисе, а также передачи обработанной информации в системы-потребители. Кроме того,
потребуется решение организационных вопросов формирования и ведения стандартизованных метаданных, в том числе с использованием классификаторов и справочников, содержащихся в федеральных государственных информационных системах и Службе информационных ресурсов ВС РФ.
Следует отметить, что создание унифицированного сервиса взаимодействия является сложной организационно-технической задачей, для решения которой придется не только разрабатывать программное обеспечение, но и активно задействовать при его использовании военных специалистов из числа должностных лиц органов военного управления.
В целом замена протоколов ИТВ на унифицированный сервис взаимодействия позволит существенно снизить затраты на обеспечение информационного взаимодействия АС ВН.
Создание и внедрение унифицированного сервиса взаимодействия станет еще одним шагом на пути к обеспечению интероперабельности АС ВН и интеграции информационных ресурсов в интересах формирования Единого информационного пространства Вооруженных Сил Российской Федерации.
1 Система межведомственного элек- Система межведомственного электрон-тронного взаимодействия (СМЭВ). U RL: ного взаимодействия (СМЭВ).
ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННО-ТЕХНИЧЕСКОГО СОПРЯЖЕНИЯ АВТОМАТИЗИРОВАННЫХ СИСТЕМ НА ПРОГРАММНОМ УРОВНЕ С ПОМОЩЬЮ МОДУЛЬНЫХ ТРАНСПОРТНЫХ ШЛЮЗОВ
автоматизированная система; информационно-техническое взаимодействие; модульные программные средства; обмен электронными документами; транспортный протокол.
О л л С
Рассмотрена задача информационно-технического взаимодействия автоматизированных систем на программном уровне в части, касающейся транспортного сопряжения. Показано различие между информационными и транспортными протоколами передачи данных, являющихся априорной информацией для решения данной задачи, а также предложен подход, при котором сопряжение существующих автоматизированных систем осуществляется без их модификации, но с использованием новой автоматизированной системы сопряжения, представленной распределенным комплексом программных и аппаратных средств.
Кратко описана внутренняя структура автоматизированной системы сопряжения, перечислены основные ее подсистемы. Введено понятие шлюза транспортного сопряжения, являющегося программной реализацией транспортного протокола передачи данных. Показан алгоритм функционирования шлюза и его место среди других компонентов. Обоснован выбор модульной архитектуры для построения таких шлюзов.
Предложен новый подход к организации модульных программных средств, в основе которого лежит снятие ограничений на входные и выходные параметры программ, содержащиеся в этих модулях, что позволяет автоматически формировать межмодульные каналы передачи данных. Введено понятие микроядра, дано его математическое описание и разработана программа реализация, позволяющая создавать модульные программные средства в рамках предложенного подхода.
Для управления модульными приложениями в ручном и автоматическом режимах разработан программный комплекс контроля и управления функционированием микроядра, позволяющий изменять структуру этих приложений в режиме реального времени. Разработанный комплекс обладает универсальностью: он может быть использован для интеграции процесса управления любыми программными средствами.
Рассмотрен алгоритм автоматического формирования и изменения шлюзов на уровне отдельных модулей в зависимости от состояния транспортных систем и команд системного администратора на изменение графа подключений автоматизированных систем между собой.
Таким образом, применение микроядра для построения транспортных шлюзов позволяет повысить отказоустойчивость и адаптивность автоматизированной системы сопряжения в целом, а также сделать процесс разработки новых шлюзов более эффективным, что подтверждено в ходе испытаний. Результаты работы позволили обеспечить обмен электронными документами между автоматизированными системами, которые не имеют общих информационных и транспортных протоколов взаимодействия.
Для решения различных прикладных задач, работа над которыми ведется в Акционерном обществе «Научно-исследовательский институт точных приборов» и других организациях, было создано и внедрено множество автоматизированных систем (АС) специального назначения. В качестве результатов работы таких систем нередко выступают документы, представленные в электронной форме, при этом в процессе эксплуатации часто возникает необходимость обмена документами между системами.
Ситуацию осложняет тот факт, что до настоящего времени нет единого общепринятого способа доставки данных на прикладном сетевом уровне из одной автоматизированной системы в другую. Например, одна система может принимать и отправлять электронные документы только по электронной почте, а другая – только через сервер файлового обмена FTP.
Не исключена также ситуация, при которой сопрягаемые системы подключены к независимым сетям передачи данных, не имеющим общих межсетевых шлюзов, что исключает возможность прямого подключения по протоколам семейства TCP/IP.
Актуальность темы обусловлена тем, что решение задачи сопряжения автоматизированных систем требует соз-
дания дополнительных программных средств, способных учитывать особенности сопрягаемых АС на логическом и системном уровнях.
1. Автоматизированная система сопряжения
Логический и системныйуровни взаимодействия АС можно иначе формулировать как информационное и транспортное сопряжение соответственно. Информационное сопряжение с некоторой автоматизированной системой определяется информационным протоколом (ИП) функционирования этой системы – совокупностью принятых в ней формализованных правил формирования и обработки электронных документов.
Технические вопросы приема и передачи документов через какое-либо программное средство объединим в понятие транспортного протокола (ТП) функционирования автоматизированной системы, который описывает транспортное сопряжение с этой системой.
Блоки данных, передаваемые по транспортному протоколу, будем называть транспортными пакетами. Например, транспортный пакет, передаваемый по электронной почте представляет собой электронное письмо, у которого адреса отправителя и получателя указаны в формате электронной почты, а передаваемый документ оформлен в виде вложения. При этом в документе могут быть указаны, например, фамилии отправителя и получателя уже в соответствии с информационным протоколом передачи.
На рис. 1 изображены две автоматизированные системы АС1 и АС2, которые работают по разным информационным и транспортным протоколам. Эти протоколы являются априорной информацией в задаче сопряжения систем и не подлежат изменению. Мы не имеем права и возможности изменять эти системы и вмешиваться в их работу, т. к. они сданы в эксплуатацию и находятся на дежурстве.
Рис. 1. Алгоритм работы шлюзов транспортного сопряжения
Поскольку при заданных условиях передача данных между системами напрямую невозможна, необходимо добавить новый элемент структуры – автоматизированную систему сопряжения (АСС), которая, используя только информацию о протоколах сопрягаемых систем, способна обеспечить информационное и транспортное сопряжение. Другими словами, если информационные и транспортные протоколы задают соответственно множества электронных документов и транспортных пакетов, то АСС отображает множество документов и транспортных пакетов одной системы во множество документов и транспортных пакетов другой.
Если сопрягаемые автоматизированные системы подключены к независимым каналам передачи данных, то может потребоваться несколько экземпляров АСС. В таких случаях АСС становится распределенной и должна обеспечивать транзитную передачу данных.
2. Элементы внутренней структуры АСС
АСС включает в себя ряд подсистем, которые обеспечивают обработку, промежуточное хранение, маршрутизацию и передачу электронных документов, ведение журнала сбоев и нештатных ситуаций, контроль и управление функционированием комплекса в целом и др.
Перечисленные подсистемы не могут быть эффективно реализованы в рамках единого программного приложения в силу специфики предметной области. Для взаимодействия с сопрягаемыми системами элементы АСС нередко работают на нескольких физических и виртуальных серверах, находящихся под управлением различных операционных систем, а также подключенных к независимым сетям передачи данных.
3. Модульные шлюзы и микроядро
Традиционные способы разбиения программных средств на модули, как правило, предполагают выделение центральной части приложения – ядра, которое обладает априорной информацией о том, какие модули могут быть к нему подключены и как они могут взаимодействовать между собой.
В ходе исследования было установлено, что если ядро приложения вместо использования априорной информации о модулях может вычислить все необходимые параметры модулей автоматически в процессе работы, то получаемые при этом программные средства обладают новыми свойствами, имеющими практическую и теоретическую значимость. По аналогии с терминами, принятыми в теории операционных систем, указанную центральную часть модульных программ предложено назвать микроядром.
Проиллюстрируем данный подход на примере подсистем приема, передачи и преобразования транспортных пакетов, которые будем называть шлюзами транспортного сопряжения или просто шлюзами. Заметим, что шлюз сопряжения с некоторой автоматизированной системой должен быть реализован в соответствии с транспортным протоколом этой системы, т. е. именно внутри шлюза должно быть реализовано транспортное сопряжение.
После преобразования информационной части документа начнется отправка в систему АС2, т. е. произойдет зеркальная последовательность действий, подготавливающих и отправляющих данный документ через шлюз сопряжения с АС2. В разных шлюзах присутствуют как одинаковые компоненты, так и специальные, учитывающие особенности информационного и транспортного протоколов той системы, с которой осуществляется сопряжение. Все эти компоненты, которые выделены в отдельные модули, состоят из подпрограмм, каждая из которых выполняется в ответ на какое-либо событие. Например, передача транспортного пакета начинается в тот момент, когда его преобразование завершено.
Таким образом, для разбиения шлюза на модули необходимо определить все необходимые подпрограммы и события и разделить их по модулям таким образом, чтобы при возникновении события в одном модуле подпрограмма в другом модуле начинала бы свое выполнение.
Опишем данный принцип более строго. Пусть Р – это множество всех возможных подпрограмм, которые могут выполняться в шлюзе сопряжения, а Е – множество всех событий, которые могут приводить к выполнению этих подпрограмм. Тогда модуль шлюзаМ-это набор элементов (Р1, Е, р0), где Р и Е – подмножества множеств Р и Е соответственно, ар0~ стартовая подпрограмма модуля (р е Р’).
Два отображения sige: Е ^ X* и sigp: Р ^Х* позволяют получить из элементов множества событий и элементов множества подпрограмм соответственно их сигнатуры -цепочки над алфавитом X, которые однозначно идентифицируют каждое событие и каждую подпрограмму, а также их входные параметры.
Если шлюз сопряжения состоит из модулей М1 = (Р1,
сто отношение К подключения подпрограмм и событий, которое является подмножеством декартова произведения объединения множеств подпрограмм и объединения множества событий:
Таким образом, микроядро, являясь программной реализацией отношения
для набора подключенных модулей способно обеспечивать связи между ними, получая множества событий и подпрограмм каждого модуля уже в процессе работы.
Теперь покажем структуру модульного шлюза (рис. 2), построенного на основе синтеза тех данных, которые хранятся в модулях. При этом алгоритм работы остался прежним. Полученный документ извлекается из транспортного пакета и сохраняется на жестком диске, после чего документ регистрируется в очереди.
Заметим, что транспортный пакет во внутреннем формате АСС, который должен сформировать шлюз, состоит из передаваемого документа и транспортного файла, внутри которого указан ряд параметров, таких как код документа, адреса отправителя и получателя в различных форматах, идентификаторы взаимодействующих автоматизированных систем и другие данные.
Когда очередь обработки доходит до полученного сообщения, модуль обработки транспортных пакетов заполняет необходимые поля транспортного файла, после чего происходит отправка пакета в другие компоненты АСС.
4. Адаптивные модульные шлюзы
Возможность составлять шлюзы и другие программные средства из отдельных модулей позволяет более эф-
Рис. 2. Алгоритм работы шлюзов транспортного сопряжения
фекгивно разделять задачи между разработчиками АСС, что приводит к сокращению времени, необходимого на их разработку. Однако более важным преимуществом предложенного подхода является тот факт, что набор модулей, из которых состоит та или иная программа, можно изменять прямо во время ее работы, а, значит, дает возможность создавать адаптивные программные средства, способные изменять свою функциональность в зависимости от условий эксплуатации.
Для внесения изменений в модульную структуру программ на основе микроядра необходима система управления ими. В рамках исследования такая система была разработана. В ее состав вошел веб-сервер администрирования, который предоставляет администратору системы веб-интерфейс для создания и изменения модульных приложений. Кроме этого, на каждом компьютере, где запускаются модульные шлюзы, в фоновом режиме должен работать диспетчер – программное средство, которое способно принимать и выполнять команды из различных источников (в т. ч. от веб-сервера) на создание, удаление и модификацию этих шлюзов.
Из предложенной структуры КУФ следует, что допускается создание модульных программ на основе микроядра, которые транслируют свои собственные параметры
в параметры какого-либо другого программного комплекса. Это позволяет связать в одно целое процесс просмотра и изменения настроечных параметров произвольных программных средств в едином интегрированном веб-интерфейсе администрирования.
В тех случаях, когда связь между автоматизированными системами может осуществляться с использованием нескольких транспортных систем одновременно, реализация всех соответствующих транспортных протоколов может быть объединена в едином многоканальном шлюзе (рис. 3). На рисунке изображен пример четырехканального шлюза, состоящего из микроядра и нескольких одновременно функционирующих модулей. Внешние адаптеры являются группой модулей, отвечающих за отправку и прием транспортных пакетов в формате сопрягаемой автоматизированной системы АС1. Соответствующие им модули-обработчики производят преобразование транспортных пакетов из формата сопрягаемой системы во внутренний формат АСС и обратно. Внутренние адаптеры подключаются к системе локального транспорта, предоставляя четыре адреса в терминах СЛТ, на которые сервер маршрутизации может высылать сообщения. Очередь на обработку представлена модулем, который регистрирует все проходящие через шлюз электронные документы и следит за тем, чтобы в каждый момент времени адаптеры и обработчики были заняты передачей одного сообщения.
Отправка документа через любую из транспортных систем должна сопровождаться получением квитанции -отчета об успешной доставке документа в АС получателя. Анализируя размер переданного документа и время, прошедшее от начала передачи до получения квитанции, модуль, обслуживающий очередь обработки, может сформировать технологическое сообщение для сервера маршру-
Рис. 3. Многоканальный шлюз сопряжения
Рис. 4. Алгоритм управления шлюзами
тизации, которое будет доставлено через систему локального транспорта. Технологический пакет будет отправлен и в том случае, если квитанции об успешной доставке перестали поступать, либо внешний адаптер получил сигнал о потере связи с транспортной системой.
Получив вспомогательное сообщение, сервер маршрутизации должен внести изменения в базу управляющих данных, устанавливая коэффициент пропускной способности для соответствующей транспортной системы, который может оказаться равным нулю при потере связи. При построении маршрутов передачи последующих электронных документов сервер маршрутизации будет учитывать данные коэффициенты каждой транспортной системы.
Сервер маршрутизации АСС может выслать диспетчеру через СЛТ специальное сообщение с командой на удаление модулей, отвечающих за транспортную систему, которая перестала функционировать. Если же администратором системы в базу управляющих данных добавляется информация о новых транспортных системах, то аналогичным образом сервер маршрутизации отправит сообщение для добавления модулей в существующий шлюз, либо на создание нового шлюза, изменяя, тем самым, граф связей автоматизированных систем и динамически перестраивая маршруты передачи документов.
Автоматическая адаптация шлюзов под текущее состояние каналов и программных средств связи (рис. 4) стала возможной именно благодаря предложенной модульной структуре, основанной на микроядре. Такой подход позволяет повысить среднюю пропускную способность и отказоустойчивость сопрягающей автоматизированной
системы АСС, в т. ч. при деградации взаимодействующих систем и каналов связи.
Предложенный подход к построению модульных программных средств отличается от известных тем, что используется микроядро – программа, которая служит для создания межмодульных связей в режиме реального времени. Данная система позволяет управлять потоками сообщений, перенаправляя и дублируя потоки, изменяя набор подключенных модулей без остановки и перезапуска микроядра.
На основе предложенного микроядра получен способ формирования модульных адаптивных шлюзов транспортного сопряжения, которые способны обеспечивать передачу электронных документов между автоматизированными системами, которые не имеют общих транспортных протоколов. При этом построение маршрута передачи каждого документа осуществляется с учетом текущего состояния каналов передачи данных.
1. Садаладж П. Дж., Фаулер М. NoSQL: новая методология разработки нереляционных баз данных: пер. с англ. М.: Вильяме. 2013. 192 р.
2. Кормен Т. Х., Лейзерсон Ч. И., Ривест Р. Л., Штайн К. Алгоритмы: построение и анализ: пер. с англ. 2-е изд. М.: Вильяме. 2005. 1293 с.
3. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования : пер. с англ. С Пб.: Питер. 2013. 368 с.
4. Брукс Ф. Проектирование процесса проектирования: записки компьютерного эксперта: пер. с англ. М.: Вильяме. 2013. 464 с.
5. Пайлон Д., Майлз Р. Управление разработкой ПО: пер. с англ. С Пб.: Питер. 2014. 464 с.
6. Ахо A. B., Лам М. С., Сети Р., Ульман Д. Д. Компиляторы: принципы, технологии и инструментарий: пер. с англ.
М.: Вильяме. 2011. 1184 с.
7. Саммерфилд М. Qt. Профессиональное программирование. Разработка кроссплатформенных приложений на С++: пер. с англ. С Пб.: Символ-Плюс. 2011. 560 с.
8. Уильяме Э. Параллельное программирование на С++ в действии. Практика разработки многопоточных программ: пер. с англ. М.: ДМК Пресс. 2012. 672 с.
Королев А. С. Обеспечение информационно-технического сопряжения автоматизированных систем на программном уровне с помощью модульных транспортных шлюзов // Наукоемкие технологии в космических исследованиях Земли. 2016. Т. 8. № 5. С. 63-69.
PROVIDING INFORMATION AND TECHNICAL INTERFACE OF AUTOMATED SYSTEMS AT SOFTWARE LEVEL USING THE MODULAR MEDIA GATEWAYS
Alexander S. Korolev,
In this paper we consider the problem of information-technical interaction of automated systems at the program level in respect of the transport interface. Firstly, we highlight the difference between information and transport data protocols, which are a priori information for solving this problem. Secondly, there is an approach suggested, whereby the interface of existing automated systems is carried out without modifying them using a new interface automated system provided by the distributed set of software and hardware means. Besides, the internal structure of the interface automated system is briefly described and its main subsystems are enumerated. The introduced term is a transport interface gateway, which is a software implementation of the transport data protocol. The algorithm of the functioning of the gateway and its place among other components are shown. Moreover, the choice of a modular architecture for building such gateways is justified.
Furthermore, we suggest a new approach to the organization of modular software means, which is based on the removal of restrictions on the input and output parameters of the programs contained in these modules, allowing to automatically generate inter-module data channels. The paper also introduces the notion of a microkernel and gives its mathematical interpretation. What is more, a software implementation allowing to create modular software within the proposed approach is received.
To manage modular applications in manual and automatic modes software system of operation management and control has been developed. It allows to change the structure of these applications even while they work. The obtained system is versatile and can be used for integration of management process of any software means. Мы рассмотрели алгоритм автоматической генерации и
В ходе исследования прогнозировано и подтверждено, что использование микроядра для построения транспортных шлюзов позволяет повысить устойчивость и адаптивность интерфейсной автоматизированной системы в целом, а также сделать процесс разработки новых шлюзов более эффективным. Результаты работы позволили осуществлять обмен электронными документами между автоматизированными системами, не имеющими общих информационных и транспортных протоколов взаимодействия. Ключевые слова: автоматизированная система; электронный обмен документами; информационно-техническое взаимодействие; модульные программные средства; транспортный интерфейс.
1. Садаладж П. Дж., Фаулер М. Дистиллированный NoSQL: Краткое руководство по развивающемуся миру полиглотов. Аддисон-Уэсли, 2012. 362 стр.
2. Кормен Т. Х., Лейзерсон К. Э., Ривест Р. Л., Стейн К. Введение в алгоритмы. Мит Пресс, 2001. 1202 с.
3. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения. Аддисон-Уэсли, 1994. 416 стр.
4. Брукс Ф. Дизайн дизайна: Очерки компьютерного ученого. Аддисон-Уэсли, 2010. 448 стр.
iНе можете найти то, что вам нужно? займитесь подбором литературы.
5. Пилон Д., Майлз Р. Руководитель отдела разработки программного обеспечения. О’Рейли, 2008. 477 стр.
6. Ахо А. В., Лам М. С., Сетхи Р., Ульман Дж. Д. Составители: принципы, приемы и инструменты. 2-е издание. Пирсон, 2007. 1038 стр.
7. Саммерфилд М. Продвинутое программирование на Qt: создание отличного программного обеспечения с помощью C++ и Qt. Аддисон-Уэсли, 2010. 554 стр.
8. Уильямс А. Параллелизм C++ в действии. Практическая многопоточность. 2012. 672 с. Manning Publications, 2009. 337 стр.
Информация об авторах:
Королев А. С., главный специалист, Акционерное общество «Научно-исследовательский институт точных приборов».
Королев А. С. Обеспечение информационно-технического интерфейса автоматизированных систем на программном уровне с использованием модульных медиашлюзов. Исследования H&ES. 2016. Том. 8. № 5. Стр. 63-69.