Промышленные предприятия активно внедряют цифровые технологии и переходят на российские ИТ-решения в рамках политики импортозамещения. Успех цифровой трансформации зависит от комплексного подхода, основанного на поэтапном движении от текущего состояния «как есть» к желаемому «как должно быть». Рассмотрим гибридный подход к развитию ИТ-ландшафта предприятия и примеры встраивания в инфраструктуру современных приложений, созданных, в частности, на основе искусственного интеллекта.

Современные платформы используют два основных типа архитектур: монолитную и микросервисную. Монолитная система строится как единое целое, включающее пользовательский интерфейс, сервер и базу данных. При таком подходе все изменения требуют полной пересборки системы, но решения просты в развёртывании (с учётом централизованной отладки), чаще демонстрируют высокую производительность, упрощают обеспечение безопасности и эксплуатацию.

Микросервисная архитектура предусматривает создание множества отдельных компонентов, каждый из которых решает свою задачу и взаимодействует с другими через сетевые протоколы (например, HTTP). Это обеспечивает гибкость и независимость модулей. Однако внедрение микросервисов повышает сложность сопровождения и приводит к необходимости использования продвинутых DevOps-практик (автоматизации CI/CD, контейнеризации и оркестрации с использованием, например, Kubernetes).

Монолитные решения подходят для стабильных бизнес-процессов, микросервисы эффективны там, где требуются частые изменения и адаптация, например в аналитике или оптимизации производства. Выбор архитектуры с учётом специфики предприятия позволит обеспечить баланс между стабильностью и гибкостью, снизив расходы на поддержку и разработку.

Монолитные системы

Для автоматизации устоявшихся процессов применялись импортные и российские продукты, в том числе АСУ ТП, АСОДУ (система оперативного диспетчерского управления), MES-системы.

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

MES-компоненты обеспечивают поддержку производственных процессов, включая диспетчеризацию производства, в том числе управление сырьём, заказами, отслеживание степени выполнения плана; оперативное календарное планирование; управление качеством продукции и техническим обслуживанием; оценку уровня производительности, учёт рабочего времени и простоя, формирование отчётности; управление товарно-сырьевыми потоками и др.

Технологии монолитных разработок, проверенные многолетним опытом, могут применяться службами эксплуатации, в том числе при изменении производственных процессов. Нет необходимости обеспечивать и содержать штат специалистов. Возможна в таких случаях уже устоявшаяся практика техподдержки по телефону.

К преимуществам монолитной архитектуры относятся:

• Простое развёртывание. Использование одного исполняемого файла или каталога упрощает развёртывание, отсутствует необходимость управлять множественными сервисами, настраивать сложные системы оркестрации или координировать развёртывание нескольких компонентов.
• Быстрота первоначальной разработки. Приложение легче разрабатывать, когда оно создано с использованием одной базы кода, не нужно тратить время на проектирование механизмов межсервисного взаимодействия.
• Производительность. В централизованной базе кода и репозитории один интерфейс API может выполнять функцию, которую при работе с микросервисами реализуют многочисленные API.
• Упрощённое тестирование и отладка. Весь код располагается в одном месте, что облегчает отслеживание выполнения запросов и поиск источников проблем. Сквозное тестирование проводится быстрее и эффективнее, поскольку тестируется единый централизованный модуль, а не распределённая система. Централизованная система логирования позволяет легко отслеживать ошибки и анализировать поведение всего приложения.

Микросервисный подход

Рассмотрим аналитическую пирамиду (рис. 1). Внизу находятся транзакционные системы OLTP (Online Transaction Processing), работающие в реальном времени, выше – системы бизнес-аналитики, такие как хранилища и витрины данных, OLAP-системы (Online Analytical Processing) для углублённого анализа. Верхний уровень занимают аналитические приложения, помогающие принимать взвешенные управленческие решения на основе данных.

По мере движения от основания пирамиды к её вершине детальные операционные данные преобразуются в агрегированную информацию.

Для задач моделирования по оптимизации технологических и производственных процессов логично применять микросервисы, используя их преимущества в гибкости и автономности команд разработки, непрерывности развёртывания и ускоренных циклах релизов (CI/CD), гибком масштабировании, независимом тестировании за счёт контейнеризации и оркестрации, поскольку команды стремятся увеличить скорость разработки, и каждая следующая модель или оптимизация существующей может происходить независимо с использованием различного инструментария.

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

Может показаться, что труд разработчика становится проще, но нет: компонентов много, система разрастается, управлять ею труднее. Самое сложное – понять, как расположить элементы, чтобы инфраструктура была максимально эффективной и при этом не увеличить затраты на оборудование. Вручную это долго и тяжело.

Kubernetes возник как инструмент для автоматизации процесса развёртывания контейнерных приложений, значительно упростив работу программистов и системных администраторов, став основой современного DevOps-подхода. Разработчики получили возможность самостоятельно и многократно развёртывать программы без участия админов, которым теперь достаточно следить за состоянием платформы Kubernetes, поскольку при авариях и сбоях она автоматически восстанавливает работоспособность приложений.

Платформа Kubernetes, предлагающая удобный каркас для управления распределёнными системами, отвечает за горизонтальное масштабирование приложений, обработку отказов, балансировку нагрузки, мониторинг и ведение журнала событий. Обеспечивая свободу выбора разработчиками инструментов и языков программирования, платформа предоставляет возможность создавать независимые микросервисы, свободно общающиеся между собой через стандартные интерфейсы вроде RESTful API и стандартных протоколов обмена сообщениями (HTTP, AMQP).

Микросервис – автономный процесс, поэтому можно разрабатывать и развёртывать каждый компонент отдельно. Если изменить один элемент, то не нужно изменять или развёртывать какой-то другой сервис (правда, только если API не изменяется или изменяется обратно совместимым образом).

При многих преимуществах микросервисов отдельные команды могут расходиться в технических решениях, что вызовет ряд проблем:

• множественные решения общих потребностей в рамках всей организации нарушают принцип «Не повторяйся»;
• разработчики, желающие сменить команду или перейти в другую, сталкиваются с необходимостью изучения нескольких технологических стеков и архитектурных решений;
• операционным командам, которые проверяют и развёртывают несколько приложений, приходится учитывать технологические решения каждой команды.

Как показывает практика, с учётом опыта развития монолитов, уровня зрелости предприятия целесообразно выстраивать гибридный ИТ-ландшафт предприятия.

Гибридная платформа

Современная единая цифровая платформа включает монолитные и микросервисные приложения. Монолитные организованы согласно классической структуре автоматизации, микросервисы представляют собой отдельные небольшие элементы, размещённые на разных серверах – реальных компьютерах, виртуальных машинах или в облаках (частных, публичных либо смешанных). Обобщённая схема гибридной цифровой платформы приведена на рис. 2.

Для промышленных предприятий важно отстраивать систему оперативного производственного управления на гибридной платформе с отслеживанием различных требований:

• рыночных, ориентированных на достижение целевых показателей по каждому товару, рынку на определённый период;
• операционных, направленных на эффективное использование ресурсов организации для производства конкурентоспособных продуктов и услуг;
• экологических, призванных решить конфликт/противоречие между экономическими и экологическими интересами;
• кадровых, касающихся формирования высокопрофессионального, сплочённого и ответственного коллектива для достижения долгосрочных целей.

Создание приложений: от «как есть» к «как должно быть»

К основным ключевым целевым показателям производства относятся:

• производительность труда;
• показатели качества продукции по ГОСТ Р ИСО 9000–2015, ГОСТ 15467–79;
• экологические показатели, объём инвестиций и текущих затрат, направленных на охрану окружающей среды в разрезе основных видов экономической деятельности;
• материалоотдача, определяемая как стоимость выпущенной за год продукции к вложенным материальным затратам.

Рассмотрим примеры встраивания в гибридную инфраструктуру предприятия приложений, помогающих улучшать производственные показатели и повышать общую эффективность предприятия.

Система управления простоями, или OEE-подход

Показатель OEE представляет собой отношение продуктивного времени работы (идеального времени производства) к плановому времени работы. С учётом потерь производительности и качества этот коэффициент может быть рассчитан по формуле:

качество × производительность × готовность = OEE.

Значимой информацией являются простои оборудования. Смысл управления простоями оборудования (УПО) заключается в более глубоком анализе причин остановки работы. Задача управления простоями сводится к нахождению промежутков времени, когда оборудование не работало либо работало с пониженной скоростью или качеством, и классификации их согласно модели времени и дерева причин. После классификации промежутки времени агрегируются для каждой категории и получаются статистические показатели для расчёта KPI.

Анализ показателей OEE – отправная точка для решения проблем потери эффективности. Один из распространённых подходов к наблюдению – сравнение показателя OEE с некоторым целевым значением. Если разница ощутимая, нужно искать причины.

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

Таким образом, OEE/УП-система естественным образом интегрируется в информационную среду MES. Но что делать, если до внедрения OEE/УП на предприятии MES не существовало? Можно пойти двумя путями – использовать автономное решение для анализа эффективности работы оборудования или начать внедрение MES с создания информационной среды и построения системы OEE/УП на её основе.

Системы машинного зрения

Системы машинного зрения (СМЗ) в промышленности разрабатываются для решения широкого круга задач, начиная с логистики и заканчивая контролем качества продукции. Одной из базовых функций СМЗ является считывание идентифицирующих изделий кодов, таких как штрихкоды и QR-коды, что существенно упрощает учёт и отслеживание товаров на различных этапах производства и логистической цепочки.

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

В таком варианте использования СМЗ решает следующие задачи:

• Обнаружение и прослеживание деталей по этапам технологического процесса. Основные методы обнаружения – использование штрих-кодов, RFID-меток и оптического распознавания объектов. Шаговая автоматизация процесса возможна благодаря интеграции автоматизированных систем слежения и компьютерному управлению оборудованием.
• Контроль соблюдения технологических регламентов и производственных операций с помощью датчиков и сенсоров, фиксирующих показатели давления, температуры, влажности и вибрации оборудования. Интеграция этих устройств с системами промышленной аналитики обеспечивает мгновенное реагирование на отклонения от нормы, что позволяет предотвращать аварийные ситуации. Особая роль отводится алгоритмам машинного обучения, способным прогнозировать возможные неисправности оборудования и тем самым минимизировать риск незапланированных простоев.
• Контроль качества продукции и выявление дефектов на основе сочетания автоматического осмотра готовых изделий и глубокого анализа данных. С помощью высокочувствительных камер и лазерных сканеров производители осматривают корпус, двигатель, трансмиссию и прочие элементы машины. Обработанные по специальным алгоритмам данные позволяют выявить мельчайшие повреждения поверхности или нарушения формы деталей.

Пилотные внедрения СМЗ проведены на ряде промышленных предприятий.

Для более детального изучения возможностей и применения систем машинного зрения в промышленной автоматизации можно ознакомиться в источнике [4], где представлены комплексные решения и успешные кейсы внедрения СМЗ.

Прогнозные модели (ML)

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

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

Существует зависимость между измеряемыми технологическими параметрами и набором зависимых целевых показателей, которые не измеряются либо измеряются редко. Определяется степень корреляции, и на основе этих данных гипотеза подтверждается или опровергается. Опыты разработки с виртуальными анализаторами, по сути ПС, публикуются достаточно часто [1–3]. Данный подход был реализован при создании модели качества дизельного топлива (рис. 3), получаемого с технологической установки первичной переработки нефти на нефтеперерабатывающем заводе (НПЗ) [3].

Одной из существенных характеристик качества выходного продукта была температура 90 %-ной верхней точки кипения дизельной фракции (T, 320–350 °С). Прямое измерение стационарными средствами температуры дизельного топлива (ДТ) не производится ввиду сложности конструкции колонны. При этом дважды в сутки выполняется лабораторный анализ выходного продукта. В силу объективных причин (высокое качество ведёт к перерасходу ресурсов) анализировать необходимо непрерывно. Разрабатывается модель для прогнозирования температуры ДТ как целевого параметра и получения значения в моменты времени по измерениям косвенных параметров технологического процесса (с учётом параметров режима эксплуатации, характеристик оборудования и сырья).

В рассматриваемом эксперименте в качестве исходных данных были взяты: 27 технологических параметров, примерно 18 тыс. записей технологических данных для одного параметра, 486 тыс. записей из архива, восемь алгоритмов для моделей (Extra Trees, Random Forest, K-Nearest Neighbors и др.). При создании модели была проработана обучающая выборка на 70 % данных. Тестовая выборка – из оставшихся значений набора.

В результате модель позволила прогнозировать значение температуры кипения ДТ в моменты измерения косвенных параметров данного процесса. За основу была взята модель целевого параметра – ансамблевый алгоритм машинного обучения Extra Trees (на 250 деревьев решений). Точность расчёта параметра модели в два раза выше по сравнению с существующими расчётными методами. Такой тип модели можно использовать в качестве советчика для операторов и диспетчеров. Дальнейшее применение модели расчёта показателя качества продукта позволит оказывать влияние на качество управления технологическим процессом установки.

Другой пример – применение ПС для оптимизации стратегий техобслуживания за счёт раннего обнаружения отклонений в работе оборудования. Для построения предиктивной модели используется большой объём исторических данных с датчиков, описывающих нормальный режим работы оборудования. На основе таких данных формируется статистическая модель или «цифровой портрет» нормального режима работы, с которым сравниваются данные реального оборудования (рис. 4).

Построенная модель управляется данными (Data driven) и не зависит от физических свойств оборудования, но алгоритмы распознавания выявляют отклонения в работе оборудования в реальном времени.

При этом формируются предупреждения двух уровней. Когда нормальная работа оборудования отличается от исторической нормы, это предупреждение первого уровня, сигнализирующее о том, что необходимо следить за работой оборудования. Предупреждение второго уровня означает, что нужно предпринять действия для устранения отклонения в работе, предотвращения отказа оборудования.

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

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

Интеграционная платформа

Связность, обмен данными и взаимодействие разнородных приложений, сервисов и оборудования на предприятии обеспечивает интеграционная платформа. Для интеграции используются стандартные протоколы и интерфейсы: API, OPC UA, MQTT и др. Поддерживается добавление новых приложений и сервисов без необходимости внесения глобальных изменений в архитектуру.

Созданные на основе платформы информационные системы обеспечивают поддержку технологических процессов в виде выполнения расчётов производственных показателей. На данной платформе могут быть реализованы различные системы расчёта показателей OEE, диспетчерские системы, ситуационно-аналитические центры.

Типовой проект интеграционной платформы включает следующие основные компоненты:

• наращиваемая библиотека графических объектов для поддержки HMI;
• пакет Servers I/O (серверов ввода – вывода) для обмена данными с контроллерным уровнем;
• пакет интеграционных протоколов для обмена данными с соседними системами и системами верхнего уровня;
• инструменты для обработки данных;
• инструментарий для загрузки моделей в контейнеры и обеспечения взаимодействия.

Гибридная архитектура интеграционной платформы, сочетающая монолитные приложения и микросервисы, накладывает дополнительные требования к обеспечению информационной безопасности. Монолитные компоненты могут быть уязвимы из-за сложности масштабирования и обновления, тогда как микросервисная архитектура, несмотря на свою гибкость, предусматривает большое количество взаимодействующих сервисов, что расширяет поверхность атаки. Следовательно, безопасность должна обеспечиваться на уровне не только каждого отдельного сервиса, но и всей инфраструктуры, включая межсервисные коммуникации, контроль доступа и мониторинг.

Особое внимание следует уделять механизмам аутентификации, авторизации и защите данных на стадии разработки, в процессе внедрения и функционирования (runtime). Также важно внедрять систему мониторинга и реагирования на инциденты безопасности, поскольку своевременное обнаружение и устранение угроз минимизируют потенциальный ущерб. Комплексный подход к информационной безопасности на всех этапах проектирования и эксплуатации интеграционной платформы – гарантия надёжной работы систем промышленной автоматизации и защиты предприятий от киберугроз.

Выводы

В настоящее время автоматизация и цифровизация – это уже не опции, а стратегии, обеспечивающие поддержание конкурентоспособности, повышение качества, устойчивости и инновационного развития промышленных предприятий. Единая интеграционная платформа, обеспечивающая связность ИТ-решений и бизнес-процессов, помогает установить «единственную правду» для руководства при принятии решений.

Гибридная платформа, объединяющая монолитные приложения и микросервисы – компоненты, распределённые на физических и виртуальных машинах, частных, публичных или гибридных облаках, – позволяет обеспечить интеграцию имеющихся и создаваемых систем автоматизации технологических, производственных и бизнес-процессов, сформировать единое информационное пространство для принятия точных решений.

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

Широкое использование систем усовершенствованного управления технологическими процессами (СУУТП / APC) с применением оркестрации и контейнеризации позволяет превратить собираемые данные в реальный актив, востребованный для построения предиктивных систем, систем оптимизации.

Технологии искусственного интеллекта всё шире применяются в системах автоматизации производства, наделяя их новыми качествами.

Доступные интеграционные платформы, реализованные как типовой проект, обновляются в части расширения и коррекции библиотек графических объектов, перечня серверов, коммуникационных протоколов и интерфейсов, технологий ИИ для широкого спектра информационных систем, включая унаследованные и облачные сервисы.

Литература

1. Шумихин А. Г., Зорин М. П., Немтин А. М., Плохов В. Г. Опыт разработки системы виртуального анализа показателей качества продуктов установок каталитического риформинга бензиновых фракций и системы их подстройки в режиме реального времени // Вестник ПНИПУ. Химическая технология и биотехнология. 2017. № 2.
2. Туташова Л. Г. Виртуальные анализаторы показателей качества процесса ректификации / Автоматизация и информационные технологии. Альметьевский государственный нефтяной институт // Electrical and data processing facilities and systems. 2013. № 3. V. 9.
3. Владов Р. А., Дозорцев В. М., Шайдуллин Р. А., Белоусов О. Ю. Предиктивная аналитика состояния оборудования в химико-технологических процессах // Автоматизация в промышленности. 2019. № 12. С. 44–52.
4. https://www.rtsoft.ru/project-cards/pspo/product/RITMS-OMEGA/