В настоящее время все больше руководителей средних и крупных промышленных компаний задумываются о проведении цифровой трансформации своего предприятия. Каждая компания вынуждена стремиться к нахождению подхода оптимизации производства, чтобы оставаться конкурентно способной на рынке. Для промышленных предприятий таким подходом может стать цифровая трансформация с использованием идей Индустрии 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 — делать известным) заинтересованных устройств.
