Scientific journal
Modern problems of science and education
ISSN 2070-7428
"Перечень" ВАК
ИФ РИНЦ = 1,006

THE TASK OF DIFFERENT INFORMATION SYSTEMS INTEGRATION OF ENTERPRISE

Sysoletin E.G. 1 Aksenov K.A. 1 Kruglov A.V. 1
1 Ural Federal University named after First President of Russia B.N. Yeltsin
In this paper is considered the task of different information systems integration of enterprise. Decision of enterprise information systems integration task based on idea of enterprise services bus. Developments and applications of module of data exchange with enterprise automated systems are allowed to do: receive data from automated control systems of technological processes; receive data from corporate information systems, MES, ERP-systems; send data to corporate information systems, MES, ERP-systems; save data to data warehouse. Module of data exchange with enterprise automated systems are created the base for task of monitoring, control, simulation and consulting of improving metallurgical production full cycle. Module of data exchange with information systems are used in metallurgical enterprise information system.
information systems
integration
enterprises services bus
metallurgical production

Все современные промышленные предприятия в большей или меньшей степени автоматизированы. Информационная составляющая (интегрированность различных информационных систем (ИС) и автоматизированных решений) предприятия зачастую неоднородна. Основой информационной структуры предприятия, как правило, является ERP-подобная система. При этом, поскольку каждое предприятие имеет свои уникальные особенности в структуре, в технологических процессах, в учетной политике, ИС данного класса на момент их установки адаптировались под данное конкретное предприятие. Чем выше степень автоматизации предприятия, чем больше сотрудников вовлечены в процесс, чем глубже отражена деятельность предприятия в учетной системе — тем выше степень адаптации системы под нужды конкретного предприятия, тем более уникальной является получившаяся в результате ИС. В силу разнородности и ориентированности на разные виды деятельности (процессы) предприятия одно из частых явлений в ИС – дублирование информации.

На предприятии существуют некие производственные / технологические процессы (переделы). Автоматизация подобных процессов могла начаться даже раньше внедрения ERP-систем, для поддержания определенных параметров устанавливались контроллеры и отдельные АРМы (АСУ ТП). Рано или поздно появляется желание учитывать происходящие процессы, записывать и хранить их параметры, отображать происходящие (или произошедшие) события или текущие значения параметров на экране, увязать последовательно идущие технологические переделы между собой. Данный процесс приводит к появлению MES-подобной системы.

Как правило, крупное промышленное предприятие имеет склады (что характерно для металлургии или машиностроения). Они касаются как готовой продукции, так и промежуточного хранения продукции, сырья и материалов между переделами. Возникают задачи логистического характера, направленные на минимальную достаточность хранения, на оптимизацию транспортировки продукции и в конечном счете — на снижение издержек. Здесь обычно присутствует WMS-система.

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

  • синхронизацию идентификаторов. В разных учетных системах одна и та же сущность (технологический процесс, единица продукции, агрегат, место складирования и т.д.) имеет различные идентификаторы;
  • преобразование форм передачи информации. Одна учетная система может работать только с файлами, другая допускает общение по tcp/ip, третья собой представляет WEB-службу;
  • преобразование форматов передаваемой информации. Атрибуты, например, одной и той же единицы продукции (ЕП) отличаются в разных ИС. При этом что-то перекрывается (но имеет при этом разные имена), а что-то специфично для данного информационного слоя и совсем отсутствует в других слоях;
  • асинхронность, несвязанность между собой поступающих сообщений во времени. Поскольку интегрируемые системы — разные, где-то учет ведется автоматически, где-то — с участием человека, то, например, сообщение о создании ЕП может прийти раньше, чем сообщение о начале технологического процесса, в результате которого данная ЕП была создана.

Существует несколько способов интеграции гетерогенных ИС. Наиболее распространенным в настоящее время является подход, при котором обмен информацией происходит с участием ESB (Enterprise Service Bus, «сервисная шина предприятия»). Основная идея ESB — это концентрация обмена сообщениями между различными ИС через единую точку. Существует довольно много реализаций ESB, как свободно распространяемых, так и коммерческих. ESB достаточно легко позволяет перейти с одного протокола на другой, с одной формы передачи сообщений на другую. Но ESB — это не более чем каркас, на основании которого придется решать перечисленные выше задачи. Далеко не все ИС имеют ESB-адаптеры, поэтому переход из формы представления данных в одной системе в форму представления в другой системе обычно приходится реализовывать внутри ESB.

В данной работе предлагается несколько другая реализация задачи интеграции разнородных ИС, она связана с разработкой модуля обмена данными между автоматизированными системами предприятия (ОДАСП) автоматизированной системы выпуска металлургической продукции (АС ВМП) [1-6]. Идеология ОДАСП и ESB общая. Обмен между участниками происходит с помощью механизма событий, обрабатываемых в одной точке. Но, в отличие от ESB, при реализации ОДАСП упор делался не на охват различных протоколов, а именно на реализацию перечисленных выше задач. Таким образом, ОДАСП рассматривается не как альтернатива ESB, а как некий способ обмена, допускающий (при необходимости) совместное с ESB использование. ОДАСП включает в себя два адаптера для произвольных информационных систем на базе Oracle и MS SQL. При этом ESB может дополнить функционал ОДАСП – в том случае, если внешняя система работает не на базе перечисленных СУБД и не может общаться с ОДАСП напрямую, с использованием протоколов HTTP, SocketIO или UDP.

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

Предметная область: сущности и связи между ними

Поскольку изначально предполагается, что в обмене участвуют разнородные информационные системы, необходим некий «структурный общий знаменатель». Предметная область, реализуемая внутри ОДАСП, закрывает конфигурацию, приемлемую для большинства предприятий или производственных объединений. Для большей унификации ОДАСП оперирует «сущностями», идентификация которых производится по UUID. UUID — это идентификатор «сущности» в пределах системы в целом, его уникальность гарантируется безотносительно привязки к конкретной информационной системе. Кроме того, у той же самой сущности одновременно может присутствовать несколько пар идентификаторов — source_uuid + sid. Связка source_uuid (идентификатор внешней информационной системы) + sid (идентификатор сущности внутри этой системы) позволяет сформировать и запомнить сопоставление идентификаторов, уникальное или внутри данной информационной системы. Все три перечисленных вида идентификаторов являются строковыми, но в качестве содержимого этой строки вполне может выступать, например, значение автоматически изменяемого первичного ключа из конкретной таблицы. В реальности под «сущностью», которой оперирует ОДАСП, может быть что угодно: единица продукции, агрегат, цех и т.д.

ОДАСП собирает поступающие из смежных информационных систем параметры. Понятие параметра достаточно широкое: это могут быть число или строка, скаляр, вектор, связный список и т.д. Поскольку конечной целью является построение связного дерева происходящих на предприятии процессов (в результате которых происходит выпуск продукции), а также параметров, при которых данные процессы проходили реально, то значение поступающего параметра, как правило, привязано к некой «сущности»: к единице продукции, агрегату, цеху или предприятию целиком. «Как правило» — потому, что сформировать такую привязку можно не всегда. В частности, если параметр поступает от АСУ ТП некоего агрегата, вопросов по привязке не возникает. Но в некоторых ситуациях привязка производится позже, не на момент получения параметра от внешней информационной системы, а после ввода данных пользователем в конце смены.

На вершине иерархии «сущностей» стоит «Предприятие». Фрагмент онтологии для технологического процесса представлен на рисунке 1. Все остальное происходит в рамках некоего «Предприятия». С точки зрения работы модуля ОДАСП не имеет никакого значения, отражает ли «Предприятие» реальное юридическое лицо или нет. «Предприятий» в одной базе может быть несколько, соответственно, есть возможность отображения работы холдингов (производственных объединений). Либо второй вариант — деятельность одного реального юридического лица может быть условно разделена на несколько разных «Предприятий»: с целью проведения последующего анализа по видам деятельности, по признаку основного производства или вспомогательных операций и т.д.

Рис.1. Онтология предметной области (технологический процесс)

Внутри «Предприятия» существуют «Подразделения» (реально это, как правило, цеха, департаменты или отделы). Внутри «Подразделений» расположено некое оборудование («Агрегаты»). На «Агрегатах» допускаются для выполнения некие технологические процессы, которые объединены в «Группы процессов». «Группы процессов» служат для представления технологических цепочек (сортамента), когда не важно, на каком конкретно оборудовании выполнялся данный процесс, лишь бы он присутствовал в цепочке производства данной продукции. Можно привести такой пример: есть группа процессов «Перевозка стали». Любой реальный процесс перевозки стали будет принадлежать этой группе. При этом не важно, на каком конкретно сталевозе будет осуществлена данная конкретная операция, для нее является приемлемым любой физически существующий на предприятии сталевоз, допускающий процесс «Перевозка стали». Реальный же процесс, имеющий время начала и окончания процесса, конкретную перевозимую ЕП с известным номером плавки и другими параметрами, безусловно, происходит уже на конкретном сталевозе (т. е. «Агрегате»). Причем может выполняться только на том агрегате, для которого указанная группа процессов допустима.

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

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

События

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

  • контроль прав, проверка, может ли данный источник (данная внешняя ИС либо пользователь, зашедший и авторизовавшийся через WEB) являться инициатором данного события;
  • обработка события. Действия, выполняющиеся в ОДАСП, являются следствием возникшего события;
  • запись результатов обработки в хранилище данных;
  • публикация события. Событие (возможно, совместно с результатами его обработки на сервере ОДАСП) транслируется на все смежные ИС, имеющие право на получение таких сообщений. При этом, если ОДАСП «знает» идентификатор сущности в данной ИС, произойдет замена идентификаторов. Клиент получит данную «сущность» с тем идентификатором, который используется и является уникальным именно в рамках данной конкретной ИС. Публикация событий происходит, как правило, в формате JSON с использованием SocketIO. Такой подход позволяет подписываться на события не только информационным системам, но и WEB-клиентам (АРМам);
  • пост-обработка события. В окружении множества разнородных ИС события не обязательно приходят по порядку. Например, технологическое оборудование будет формировать параметры, связанные с данным процессом, возможно, раньше, чем начало самого процесса будет фиксировано обслуживающим персоналом. Для упорядочивания подобных ситуаций существует пост-обработка, в том числе и на основании разработанных пользователем (на языке Java) функций. За счет механизма пост-обработки могут быть реализованы произвольные функции.

Вся система АС ВМП построена на идеологии наращивания мощности, т.е. если один модуль ОДАСП не справляется с существующей нагрузкой, то параллельно ставятся несколько модулей ОДАСП. Структура системы представлена на рисунке 2.

Рис.2. Структура модуля ОДАСП, взаимодействие с внешней информационной системой, хранилищем данных и модулем интеграции моделей (ИМ)

Система имеет три типа клиентов: Web, SocketIO и UDP. В первом случае происходит выдача информации по запросу. Во втором – двухсторонний асинхронный механизм событий. В третьем – быстрая негарантированная доставка данных. Совместное использование Nginx и другого HTTP-сервера позволяет использовать все преимущества Nginx, в частности передачу в ОДАСП только динамических данных. В случае необходимости дополнительной защиты информации при работе через Интернет может быть использован HTTPS-сервер. С помощью протокола UDP происходит передача параметров. Через Socket.IO происходят подписка на нужные события и инициация этих событий со стороны различных клиентов (например, из КИС/MES/ERP). Данные, поступающие с технологического оборудования, хранятся в ХД.

Заключение

В работе решена задача интеграции гетерогенных информационных систем современного промышленного предприятия на основе использовании идеологии шины данных предприятия и разработке модуля обмена данными с автоматизированными системами предприятия. Модуль ОДАСП позволяет решать следующие задачи: получение данных от автоматизированных систем управления технологическими процессами предприятия; получение данных от КИС, MES, ERP-систем; выдачу данных в КИС, MES, ERP-системы; запись данных в хранилище данных. Модуль обмена данными с автоматизированными системами предприятия создает основу для решения последующих задач слежения, контроля, моделирования и выдачи рекомендаций по оптимизации полного цикла выпуска металлургической продукции.

Работа выполнена в рамках договора № 02.G25.31.0055 (проект 2012-218-03-167) при финансовой поддержке работ Министерством образования и науки Российской Федерации.

Рецензенты:

Доросинский Л.Г., д.т.н., профессор, заведующий кафедрой теоретических основ радиотехники, ФГАОУ ВПО «Уральский федеральный университет им. первого Президента России Б.Н. Ельцина» , г. Екатеринбург;

Поршнев С.В., д.т.н., профессор, заведующий кафедрой радиоэлектроники информационных систем, ФГАОУ ВПО «Уральский федеральный университет им. первого Президента России Б.Н. Ельцина» , г. Екатеринбург.