Документ описывает принципы, архитектуру, требования и практическую реализацию интеграционного слоя данных в автоматизированных информационных системах предприятий.
Интеграционный слой управления данными на производственном предприятии
Непрерывное развитие информационных технологий, поэтапная глобализация информационных систем оказывает мощный толчок к развитию распределенных, взаимодействующих между собой разнородных (гетерогенных) информационных систем.
При этом сами процессы создания информационных систем также претерпевают значимые изменения, связанные не столько с развитием программно-аппаратных средств, разветвленностью глобальной сети интернет, сколько с трансформацией модели реального мира, затрагивающей профессиональную ИТ среду и бизнес процессы. Соответственно, все более очевидным, растущим по значимости и объему требованием при проектировании ИС, их разработке и вводе в действие становится требование обеспечения глубокой и прозрачной интеграции между разнородными ИС.
Данные изменения определяют вектор развития систем автоматизации и инструментария для них на глобальном и на локальном уровнях, тем самым создавая новые возможности для автоматизации процессов взаимодействия автоматизированных систем.
Вектор развития систем автоматизация сдвигается в сторону цифровизации бизнес-процессов. Переход становится возможным только при совместной работе специалистов различных предметных областей, изменяя производственную культуру работы производственного персонала при тесном сотрудничестве с IT-персоналом. Ключевым словом при проектировании становится термин «модель» – это модели предметной области, это модели пред- и пост- обработки данных, это модели принятия решений на основе выполненной обработки полученных данных.
За последние годы (начиная с 2010 года особенно быстро) информационные сети, аппаратное и программное обеспечение эволюционировали в сторону организации и управления системами доступа к гигантскому хранилищу данных. А развитие сетей связи (протоколы, интерфейсы) способствовали изменению способов выполнения стандартных технологических операций с данными, а именно их сбора, хранения, передачи, обработки и представления пользователям. Если первоначально мы оперировали отформатированной текстовой информацией, то с ростом пропускной способности сетей и объемов цифровых хранилищ данных повсеместно в контент начинают внедряться статические и динамические изображения, а на сегодняшний день и видео. Техническая реализация гибкого оперирования этими данными, требует глубокой интеграции разнородных данных на каждом из этапов выполнения над ними технологических операций на всех уровнях модели OSI . Соответственно, для того, чтобы пользователь мог свободно и легко оперировать разнородной информацией, должна быть очень качественно и надёжно выполнена интеграция абсолютно разных видов обеспечения,а именно: технического, информационного, программного, организационно-системного, математического.
Уже недостаточно просто расписать интерфейсы и протоколы взаимодействия программно-технических средств [1]. Нужны механизмы, позволяющие прозрачно для пользователей ИС и с минимальными затратами для разработчиков (здесь мы говорим, в первую очередь, об архитектуре программного кода) отделить логику обработки разнородных и разно-форматных данных от самих данных. Уровень абстракции пользовательских запросов должен быть таким, чтобы разницы между доступом к тексту, графике, видео или статистике не было вовсе. Т.е. на первое место выходит понятие интероперабельности при условии сохранения функционального масштабирования [2].
Рассматривая интеграцию разнородных информационных систем как одну из важнейших задач в использовании современных информационных технологий следует отметить следующее. Промышленные предприятия при множестве разнородных и в разное время запускаемых технологических объектов (технологическое оборудование, системы управления)имеют технологические и программные решения от разных вендоров, разработчиков используемого ПО, и наивно считать, что все предприятия в итоге должны (будут) работать на оборудовании одного вендора с одной для всех программной и информационной инфраструктурой, именно поэтому нужны механизмы объединения, механизмы интеграции, обеспечивающие реализацию модели интероперабельности при работе с данными.
Пример
Для примера, рассмотрим некоторый производственный цех с несколькими участками и разнородным оборудованием. Требуется в режиме on-line контролировать показатели производства. Одним из параметров контроля возьмем KPI о работе производственного участка. Он представляется у руководителя в виде замечательного дашборда, однако каждый из представленных показателей имеет длинный, алгоритмически взаимосвязанную цепочку преобразований реальных данных.
Изначально – это аналоговые и дискретные сигналы с конкретных единиц оборудования, их хранение в промышленных базах данных, с последующей обработкой в системах производственного уровня (MES, LIMS, ТОиР и т.п.). Сюда же добавляются реальные данные производственного и экономического характера из систем корпоративного уровня с последующей аналитической обработкой по требуемым бизнес-правилам, которые нужны для «обогащения» соответствующих блоков данных. И эти данные должны быть совмещены на временной шкале и на шкале материального потока. Работать с такими данными в виде отчетов и таблиц становится практически невозможно. Требуется все больше интерактивности при работе с запросами и представлении результатов их обработки. Данное требование становится приоритетным при разработке программного обеспечения в глобальных и локальных информационных системах, оно приводит еще к одной модели хранения и представления конечных данных с необходимостью проводить преобразование в структуре и формате исходных данных. Модели, позволяющей делать преобразования «на лету», прозрачно для пользователей, и умеющей «подтягивать» нужные данные из «нужных» мест.
По нашей оценке, исходя из реального опыта выполнения интеграционных проектов, количество преобразований исходных данных «от поля» до «уровня управленца» на среднем предприятии горно-металлургического профиля достигает более 30. А количество интерфейсов, которые приходится реализовывать для того, чтобы «донести» эти данные, достигает несколько десятков, включая уровни АСУТП, АСУПП и корпоративный уровень.
Организация информационных потоков осуществляется благодаря созданию информационных связей между разными уровнями автоматизации. Количество связей, количество алгоритмов, необходимость дальнейшей поддержки и масштабирование функций интеграции приводит к необходимости создавать интеграционный слой, как отдельный объект в структуре уровней автоматизации.
Таким образом, при проектировании, разработке и вводе в действие современных информационных, автоматизированных систем следует учитывать, что:
- Сбор данных уже осуществляется из множества источников, которые могут быть распределены по всему миру;
- Обработка контента реализует алгоритмы различной направленности, т.к. при разработке большинство информационных систем ориентированы на мобильность и максимально удобный пользовательские интерфейс [3];
- Правила преобразования данных требуют «связывания» их в последовательную цепочку правил, которые определяют логику «появления» расчётного события в системе;
- Набор событий определяет необходимость создания и управления событийной моделью интеграционного взаимодействия исходя из целевой модели управления.
Интеграция как основа цифрового предприятия: вызовы, подходы и практические решения
Указанные факты требуют пересмотра архитектуры взаимодействия информационных ресурсов предприятия.
Фактическими требованиями на предприятиях разного вида деятельности становится переход к цифровому предприятию, где различные по своей сути физические процессы должны взаимодействовать друг с другом посредством цифровой (информационной) среды.
Реализация такой информационной среды становится возможной при условии инфраструктурной доступности разных приложений, систем хранения данных, систем обработки данных в режиме реального времени в гетерогенной сети [4].
Ключевым фактором информационной доступности в режиме on-line становится согласованность спецификаций обмена данных (форматы, интерфейсы, протоколы) между различными платформами их сбора, хранения и обработки, что предполагает возможность информационного обмена в режиме 24/7.
Количество информационных ресурсов, взаимодействующих друг с другом, растет в геометрической прогрессии. Рассмотренные выше факты и требования с минимальным участием человека в процессах обмена данными между системами, являются определяющими при переходе к цифровому предприятию [5].
Направленность на цифровизацию в промышленности требует от информационной среды полной виртуализации физических процессов. Модели, которые поддерживают функционирование физических процессов, должны в цифровой среде уметь управлять цифровым двойником в реальном времени и быть синхронизированы с реальными процессами, что предполагает взаимодействие разнородных информационных систем.
Какой процесс становится самым главным в заявленном векторе перехода к цифровому предприятию?
По моему мнению, это процесс интеграции в широком смысле слова [6]. Технологии развиваются очень динамично, захватывая в круговорот изменений все уровни сбора, обработки, преобразования, хранения, передачи и представления данных. И при этом каждая из перечисленных операций управления данными решается на разном уровне модели OSI с использованием оборудования и программного обеспечения различных вендоров. На сегодняшний день количество протоколов, используемых в модели OSI на всех уровнях, составляет более 120, что указывает на важность вопроса сетевого и информационного взаимодействия ИС при их проектировании и модернизации.
Попытки вендоров полностью закрывать линейкой своих продуктов рассматриваемые области работы с данными и информацией, на мой взгляд, ведут к значительным рискам в будущем на пути цифровизации и глубокой автоматизации предприятий. Другая сторона медали заключается в попытке стандартизировать правила взаимодействия цифровых систем. С этой целью в 2012 году в России появляется ГОСТ Р 55062-2012 – «Информационные технологии (ИТ). Системы промышленной автоматизации и их интеграция [7]. Интероперабельность. Основные положения», который и определяет модель для интеграции информационных систем. В практическом же русле реализация данного стандарта сильно усложнена ввиду следующих
причин:
- Различные поставщики оборудования (вендоры) (как бы мы не старались их уменьшить);
- Многообразие оборудования (сетевого, контроллерного, компьютерного) с разными драйверами, ИС настройки, сервисами и технологиями применения;
- Вовлечение в процесс создания ИС практически всех слоев персонала Заказчика;
- Отсутствие понятийного аппарата, не обременённого специфической терминологией;
- Отсутствие достаточного количества стандартизованных визуальных объектов представления данных;
- Увеличение роли организационной составляющей, ввиду увеличения круга взаимодействующих.
Рост технологических возможностей ИТ [8] позволяет строить системы автоматизации с опорой на тесную интеграцию. В качестве примера рассмотрим решение в котором применяются принципы современной интероперабельности в рамках реализации межсистемного взаимодействия АСУ разного уровня автоматизации, а именно уровня 2 АСУТП и уровня 3 автоматизации оперативной производственной деятельности предприятия по учету, мониторингу и сведению балансов по энергетическим ресурсам [9].
При проектировании системы была решено отойти от существующего подхода делить систему по видам ТЭР (технико-экономические расчеты – возможно, не всем потенциальным читателям известное сокращение) при ее проектировании. Тем самым было принято решение создать единую информационную и логическую модель комплекса в целом, охватывая все уровни автоматизации. Главной целью ставилась задача создать возможности функционального масштабирования проектируемой системы на все виды энергоносителей на долгосрочную перспективу. В рамках данной задачи выполнено следующее:
- Создана единая виртуальная сетевая среда в которой подключены разнообразные устройства, такие как датчики, компьютеры, сервера использующие разнообразные интерфейсы;
- Создана единая база знаний, которая аккумулирует информацию в рамках функционирования единой информационной модели комплекса;
- Совместно с Заказчиком разработан набор правил и процедур для действий по согласованным бизнес‑сценариям [10].
Использование данных решений, позволило добиться одной из основных задач интеграции – наращивание и масштабирование данной системы без изменений архитектуры решения. В дальнейшем Заказчик только добавляет параметры сбора, правила расчетов, визуализацию и приёмник, которые получают обновленную информацию после обработки первичных данных.
Также важным шагом на этапе проектирования была проработка вопросов взаимодействия с поставщиками систем АСУТП. Системы технологической автоматизации разных агрегатов поставляются разными вендорами, поэтому в наличии было разнообразное ПО. В рамках проекта реализовали слой универсальной логики и слой кастомизируемых драйверов под конкретные модели обрудования. Как вы понимаете, вся система сделана была не за один раз, и наследовала огромное количество уже существующих подсистем, узлов, программного обеспечения. Одновременно шли проекты локальной технологической автоматизации, где также существуют встроенные узлы управления расходом разных энергоресурсов.
Как правило, если в период проектирования локальных систем АСУ и выпуска соответствующей проектной документации на агрегат и систем его автоматизации не решили вопрос интеграции, то в дальнейшем сталкиваетесь с множеством подводных камней при проектировании и разработке ИС, вплоть до срыва сроков, ошибок в коде готового ПО или даже невозможности завершения проекта.
Практика реализации информационных систем показала, что эффективным методом, позволяющим с достаточной для функционирования надежностью оценивать корректность функционирования сложной информационной системы, становится типизирование абстракций (читай объектов) сценариев взаимодействия при согласованных спецификациях обмена, позволяющих определить процессы, протекающие в системе. Как пример – существует блок «решатель» со своими настраиваемыми входами, выходами и логикой внутренней обработки входных данных. Но здесь мы затрагиваем только часть программного блока, а существенным требованием становится возможность инфраструктуры поддерживать внутреннюю логику работы с данными разного формата и с разным таймингом обслуживания запросов.
В связи с явной востребованностью и необходимостью подобных решений в проектировании, разработке и модернизации ИС мы выработали требования к поставщикам систем, которые в дальнейшем стали являться фактически атрибутами модели интеграционного взаимодействия, названной интеграционным комплексом автоматизации (ИКА).
Далее, все эти требования потянули за собой требования к инфраструктуре, которые затрагивают не каждый по отдельности уровень модели OSI, а пронизывают все уровни модели в цепочке от поставщика до потребителя услуг (а также в обратном направлении) в режиме реального времени [11] обмена данными. Особенно актуальными указанные требования становятся в условиях гетерогенной среды и увеличивающейся сложности и интеграции разнородных информационных систем [12].
Данная логическая модель построения схемы обслуживания запросов, получения данных, их обработки и отправки ответов явилась прототипом для проектного артефакта под названием «Интеграционный комплекс автоматизации». Соответственно была выработана методика проектирования и создания ИКА, которая показала свою эффективность при реализации комплексных информационных систем в автоматизации промышленных объектов.
Перечень высокоуровневых требований к интеграции представлен в таблице. Их исполнение в процессе любого проекта автоматизации позволяет гарантированно обеспечить возникающие межсистемные связи в ходе проекта.
Возрастание роли системной инженерии в проектировании любых современных систем (умный дом, цифровой завод, телемедицина и т.п.) требует преобразования сложных процессов, протекающих в различных системах, через объединение их в одной среде взаимодействия.
Ввиду этого требуется выделять интеграцию в отдельный функциональный объект, что позволяет эффективно масштабировать информационную систему, а также увеличивать скорость её создания и ввода в действие.
Практическое применения таких разработанных методов и инструментов интеграции с применением функционального объекта «Интеграционного комплекса автоматизации», предназначенного для организации взаимодействия любых разнородных информационных систем друг с другом, позволяет сократить время на отладку взаимодействия, настройку и модернизацию информационных систем в части взаимодействия. Данные возможности ИКА позволяют при заданном качестве сбалансировать ключевые критерии любого проекта, а именно деньги, время, люди и самое главное качество информационной интеграции. ИКА это комплексное решение, позволяющее вывести предприятие на новый уровень эффективно в части принятия управленческих решений в условиях непрерывной интеграционной среды взаимодействия и информационного шума, тем самым эффективно управляя ресурсами для создания и ввода в действие сложных информационно‑взаимозависимых систем.
