В настоящее время все больше руководителей средних и крупных промышленных компаний задумываются о проведении цифровой трансформации своего предприятия. Каждая компания вынуждена стремиться к нахождению подхода оптимизации производства, чтобы оставаться конкурентно способной на рынке. Для промышленных предприятий таким подходом может стать цифровая трансформация с использованием идей Индустрии 4.0. Цифровая трансформация предприятия – это сложный и многосторонний процесс, который затрагивает практически все уровни производства. Основу этого процесса составляют данные как о работе отдельных единиц оборудования, так и производства в целом, которые необходимо собирать, хранить, агрегировать, передавать на различные уровни. Сбор данных можно осуществлять с использованием различных инструментов, как давно себя зарекомендовавших технологий, таких как OPC (Open Platform Communications), так и с применением современных решений (например, технология MT Connect, программные интерфейсы API систем управления и др.).


Способы решения проблемы


С каждым годом появляется все большее количество систем для сбора данных с технологического оборудования, такие как, например, MDC системы (англ. MDC – Machine Data Collect). Это системы, по сути, являются подклассом SCADA систем, но решают узко специализированную задачу – сбор данных для проведения аналитических исследований, либо предоставление ограниченного набора необходимых данных оператору технологического оборудования. Часто объектом применения MDC систем является оборудование с Числовым Программным Управлением, при этом производится сбор следующего набора данных: время выполнения управляющей программы, потребляемые ресурсы (например, электрическая энергия), ошибки, появляющиеся во время работы и многое другое. Указанный набор данных позволяет произвести анализ работы станка или даже целого цеха для определения причин простоя и появления нерегулярных ситуаций. Но перспективы развития MDC систем видятся нам более широкими. Среди круга возможных задач можно выделить следующие: сбор данных с Программируемых Логических Контроллеров, PAC систем и датчиков, использующих технологию IoT; передача данных на мощные аналитические платформы (например, Azure, AWS, Bosch IoT и т.д.). Также по итогам работы можно обработать и предоставить агрегированные данные в удобном для визуального восприятия формате, что позволит в дальнейшем решить проблему оптимальной реализации интерфейсов оператора технологического оборудования.


Представленная в работе платформа может получать данные посредством web-, мобильных технологий, а также c устройств виртуальной и дополненной реальности (англ. Virtual & Augmented Reality – AR/VR) без привязки к конкретной единице оборудования. Среди существующих на Российском рынке MDC систем можно выделить несколько производителей, среди которых наилучшим образом себя зарекомендовали продукты АИС Диспетчер и СМПО Foreman (оба компании входят в группу компаний Цифра). Также существует платформа Winnum, позиционирующая себя как платформа интернета вещей для решения широкого класса задач. Из зарубежных решений наибольший интерес представляют решения Bosch Rexroth IoT и MDC-MAX.


Структура CNCIOT


В МГТУ «СТАНКИН» на базе кафедры компьютерных систем управления разрабатывается специализированная MDC система, представляющая собой платформу по сбору, агрегированию и предварительной обработке данных с систем ЧПУ, ПЛК, PAC и IoT устройств. Необходимость разработки собственного решения возникла в связи с тем, что существующие системы ориентированы на крупные промышленные предприятия, что отражается в стоимости системы, а системы имеющих невысокую стоимость внедрения, ограничивают программные интерфейсы (англ. application program interface – API) для сторонних разработ-чиков или представляют полностью закрытое решение поставляемое «под ключ».


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


  • шлюз сбора данных с объекта управления посредством IoT усройств (IoTHub);
  • шлюз сбора данных с систем управления объектом (CNCHub);
  • хранилище данных мониторинга и результатов анализа (CNCIoTCloud);
  • клиенты анализа и визуализации результатов мониторинга (Решения анализа и визуализации).

Разрабатываемая цифровая платформа на нижнем уровне представляет собой два варианта: программное и программно-аппаратное решение. Первый вариант используется, если системы управления предоставляет возможность встраивания дополнительных программных модулей, не затрагивающих основные функции управления (применяется для ЧПУ «АxiOMA Control» и решений BoschRexroth). Второй вариант – использование проме-жуточного шлюза, к которому реализовано подключение вспомогательных датчиков (как проводным, так и беспроводным способом – на текущем этапе Bluetooth и Wi-Fi). Второй вариант также имеет поддержку OPC UA протокола и API нескольких систем управления, что позволяет на текущем этапе работать с ЧПУ Fanuc, Fagor, AxiOMA и MLC BoschRexroth. В оконном приложении на шлюзе сбора данных происходит наст��ойка параметров системы (например, выбор станка с ЧПУ), конечного сервера агрегирования данных, типа запраши-ваемых данных, периода опроса и т.д. К шлюзу также подключаются собственные IoT устройства с использованием MQTT протокола. Разработан первый вариант IoT решения, способного передавать данные напрямую в сервер, минуя шлюз.


Вся информация отправляется на сервер в структурированном виде посредством JSON файла.
Сервер агрегирования данных представляет собой удаленное облачное хранилище с развернутой на нем базой данных, структура которой позволяет проследить состояние конкретного параметра, привязки его к системе ЧПУ или специализированному датчику. API платформы позволяет настраивать отправку данных на промежуточные терминалы предоставления данных, включая популярные мессенджеры, собственные Web-страницы, а также получение данных для AR и VR решений (первые испытания показали перспективность применения указанных технологий, в том числе в учебном процессе для эмуляции выполнения управляющих программ ЧПУ без физического перемещения узлов станка). Сбор данных на основе интерфейсов коммуникации ЧПУ может выполняться с испытательными стендами. Это предоставляет возможности отслеживать состояние различных версий системы, отлаживать механизмы предоставления данных и воспроизводить проблемы возникающие при эксплуатации станков с учетом их настроек (т.е. реализацией цифрового двойника).


В настоящее время в представленной структуре разрабатываются и испытываются собственные решения уровней IoTHub, CNCHub и CNCIoTCloud на основе взаимодействия с системой АксиОМА Контрол, системой управления обрабатывающего центра Э7106MФ4, а также стендовыми образцами др. систем ЧПУ (Fanuc, Siemens, Fagor).


Возможна быстрая настройка через Web или мобильное приложение.


На рисунке 4 представлена структура модуля CNCIOT, осуществляющего сбор данных с технологического оборудования. Основное приложение реализовано на Qt для поддержки совместимости работы на различных программно-аппаратных платформах. Для получения данных с систем ЧПУ и ПЛК используются API, предоставляемые производителями оборудования, например, Bosch Rexroth OCE или Fanuc Focas 32. В основном это или бесплатные программные пакета или их стоимость составляет всего лишь несколько десятков евро. Также разрабатывается поддержка OPC UA клиента на базе создаваемого решения.


CNCIOT на в��ех уровнях старается поддерживать гибкий API, для предоставления данных, например, системам визуализации.


Подход к агрегированию и хранению технологических данных


Разработка и сопровождение промышленных систем мониторинга и предиктивной аналитики предъявляет новые требования при решении задач организации хранилищ данных и реализации сервис-ориентированной архитектуры приложений. Объектная модель хранилища с одной стороны должна быть достаточно гибкой и позволять хранить данные произвольного формата, с другой стороны отвечать требованиям репрезентативности технологического процесса конкретной единицы оборудования и контекстно зависимых процессов связки устройств промышленного интернета вещей, систем мониторинга и систем управления технологического оборудования. Существующий этап развития систем искусственного интеллекта и инструментов математического моделирования позволяет строить модели производственных процессов с не четко выявленными зависимостями протекания процессов. Построение математических моделей производственных систем на сегодняшний момент все больше опирается на данные полученные с технологического оборудования, что привело к появлению таких понятий как цифровые тени и цифровые двойники производственных систем. Этот факт позволяет предположить, в скором будущем предприятия будут следовать подходу Data-driven в принятии решений по созданию или оптимизации внутренних технологических процессов опираясь на анализ генеральных выборок, агрегаций и сэмплированию (от англ. sample — выборка) накопленных данных.


Для систем сбора данных на текущий момент существуют определенные проблемы, связанные с невозможностью на начальных этапах учесть все нюансы и технологии в сфере промышленной автоматизации и проблема интерпретации и стандартизация различных протоколов.
Традиционным решением для организации хранения данных являются реляционные базы данных, однако, для организации больших и отказоустойчивых хранилищ данных на сегодняшний момент используются разнообразные виды NoSQL (от англ. not only SQL — не только SQL) подход. Тип и структуру данных от промышленных систем в целом и от систем, использующих технологию промышленного интернете вещей в частности, невозможно заранее предсказать. Это связано с тем, что для получения данных могут использоваться различные механизмы, такие к��к: программные коннекторы, ориентированные на конкретный вид оборудования конкретного производителя; REST-сервисы интеграции или прямые подключения к реляционной базе данных; реализация технологии OPC UA с задаваемой частотой опроса.


Хранение данных CNCIoT


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


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


В работе в качестве основного хранилища оперативной информации с технологического оборудования принята open-source реляционная база данных PostgreSQL. В качестве базовой сущности вводится понятие «ноды», как единицы агрегации устройств в рамках процесса. В качестве «ноды» может выступать как отдельный датчик, так и связка систем управления и устройств промышленного интернета вещей, тем самым достигается контекстная зависимость хранения данных. Особенностью устройств промышленного интернета вещей в рамках контекста является разная частота опроса с устройств полевого уровня и времени актуальности собранных данных. К примеру, в рамках процесса могут быть установлены датчики работающие в сети LoRaWAN (максимальная скорость пере-дачи 50 кбит/сек), устройства взаимодействующие по REST API (зависит от установлен-ной пол��тики устройства и Backend Rate Limiting принимающего сервиса) и OPC UA (частота опроса полевого уровня 50 мс).


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


Предложенная в работе архитектура требует реализации контракта между устройством сети и веб-сервисами разработанной платформы. В качестве базового синтаксиса был использован универсальный текстовый формат JSON с рядом синтаксических ограничений на обязательность некоторых атрибутов. В качестве важных параметров выделены следующие: идентификатор устройства, группа запроса и ожидаемый формат данных. Группа запроса является отдельной сущностью и позволяет отслеживать такие устройства как системы числового программного управления, отправляющие в запросе большое количество разнообразных данных (например, показания отдельных осей или внутренние коды ошибок). Формат не позволяет задавать вложенные структуры. Вложенность структур в рамках предложенной платформы означала бы несогласованность данных (англ. data consistency) и ошибки в построение аналитических отчетов и представлений. Однако ошибочные запросы к сервисам возможны, ввиду большого разнообразия устройств и регистрируются в том виде в каком они поступили для последующей корректировки и агрегации в рамках инициированного процесса. Для случаев нарушения контракта веб-сервисы уведомляют устройство соответствующим HTTP-кодом и регистрируют на стороне платформы проблемные вызовы соответствующего устройства. Превышение заданного количества допустимых потерь и статусов ошибок запускает процесс нотификации (от лат. notificare — делать известным) заинтересованных устройств.