В настоящее время все больше руководителей средних и крупных промышленных компаний задумываются о цифровой трансформации своего предприятия.
Каждая компания вынуждена стремиться найти подход к оптимизации производства, чтобы оставаться конкурентоспособной на рынке.
Для промышленных предприятий таким подходом могла бы стать цифровая трансформация с использованием идей Индустрии 4.0. Цифровая трансформация предприятия – сложный и многогранный процесс, затрагивающий практически все уровни производства.
В основе этого процесса лежат данные как о работе отдельных единиц оборудования, так и о производстве в целом, которые необходимо собирать, хранить, агрегировать и передавать на различные уровни.
Сбор данных может осуществляться с использованием различных инструментов, как давно проверенных технологий, таких как OPC (Open Platform Communications), так и с использованием современных решений (например, технологии MT Connect, API системы управления и т. д.).
Пути решения проблемы
С каждым годом появляется все большее количество систем сбора данных с технологического оборудования, таких как, например, системы MDC (англ.MDC — Machine Data Collect).
Эти системы, по сути, являются подклассом SCADA-систем, но решают узкоспециализированную задачу – сбор данных для аналитических исследований, либо предоставление ограниченного набора необходимых данных оператору технологического оборудования.
Зачастую объектом применения систем MDC является оборудование с ЧПУ, при этом собирается следующий набор данных: время выполнения программы управления, потребляемые ресурсы (например, электрическая энергия), ошибки, возникающие в процессе работы, и многое другое.
более.
Этот набор данных позволяет проанализировать работу машины или даже целого цеха, чтобы определить причины простоев и возникновения нештатных ситуаций.
Но мы видим более широкие перспективы развития систем MDC. Среди спектра возможных задач можно выделить следующие: сбор данных от программируемых логических контроллеров, PAC-систем и датчиков с использованием технологии IoT; перенос данных на мощные аналитические платформы (например, Azure, AWS, Bosch IoT и т. д.).
Также по результатам работы возможна обработка и предоставление агрегированных данных в удобном для визуального восприятия формате, что позволит в дальнейшем решить задачу оптимальной реализации операторских интерфейсов технологического оборудования.
Представленная в работе платформа может получать данные через веб, мобильные технологии, а также с устройств виртуальной и дополненной реальности (англ.
Virtual & Augmented Reality — AR/VR) без привязки к конкретному оборудованию.
Среди существующих на российском рынке систем MDC можно выделить несколько производителей, среди которых наиболее зарекомендовавшими себя продуктами являются АИС «Диспетчер» и «Бригадир СМПО» (обе компании входят в группу компаний «Цифра»).
Также существует платформа Winnum, которая позиционирует себя как платформа Интернета вещей для решения широкого класса задач.
Из зарубежных решений наиболее интересны решения Bosch Rexroth IoT и MDC-MAX.
Структура CNCIOT
В МГТУ «СТАНКИН» на базе кафедры компьютерных систем управления разрабатывается специализированная система MDC, которая представляет собой платформу для сбора, агрегирования и предварительной обработки данных от систем ЧПУ, ПЛК, PAC и устройств IoT. Необходимость разработки собственного решения возникла в связи с тем, что существующие системы ориентированы на крупные промышленные предприятия, что отражается на стоимости системы, а системы с низкой стоимостью внедрения ограничивают прикладные программные интерфейсы (API) для сторонних разработчиков.или представляют собой полностью закрытое решение, поставляемое «под ключ».
Структуру организации дистанционного мониторинга можно разделить на четыре уровня или этапа сбора, агрегирования и обработки данных:
- шлюз для сбора данных от объекта управления через IoT-устройства (IoTHub);
- шлюз для сбора данных из систем управления объектом (CNCHub);
- хранилище данных мониторинга и результатов анализа (CNCIoTCloud);
- клиентов для анализа и визуализации результатов мониторинга (Ana Analysis and Visualization Solutions).
Первый вариант используется, если в системе управления предусмотрена возможность интеграции дополнительных программных модулей, не влияющих на основные функции управления (используется для решений AxiOMA Control CNC и BoschRexroth).
Второй вариант — использовать промежуточный шлюз, к которому можно подключить вспомогательные датчики (как проводные, так и беспроводные — на текущем этапе Bluetooth и Wi-Fi).
Второй вариант также имеет поддержку протокола OPC UA и API нескольких систем управления, что позволяет на современном этапе работать с ЧПУ Fanuc, Fagor, AxiOMA и MLC BoschRexroth. В оконном приложении на шлюзе сбора данных настраиваются параметры системы (например, выбор станка с ЧПУ), конечный сервер агрегации данных, тип запрашиваемых данных, период опроса и т.д. К шлюзу также подключаются собственные IoT-устройства.
шлюз, использующий протокол MQTT. Разработана первая версия IoT-решения, способного передавать данные напрямую на сервер, минуя шлюз.
Вся информация отправляется на сервер в структурированном виде через файл JSON. Сервер агрегации данных — это удаленное облачное хранилище с развернутой на нем базой данных, структура которой позволяет отслеживать состояние определенного параметра, привязывая его к системе ЧПУ или специализированному датчику.
API платформы позволяет настроить отправку данных на промежуточные терминалы предоставления данных, включая популярные мессенджеры, собственные веб-страницы, а также получение данных для AR и VR-решений (первые тесты показали перспективность использования этих технологий, в т.ч.
в учебном процессе по имитации выполнения управляющих программ ЧПУ без физического перемещения деталей станка).
Сбор данных на основе интерфейсов связи ЧПУ может осуществляться с помощью испытательных стендов.
Это обеспечивает возможность отслеживать состояние различных версий системы, отлаживать механизмы доставки данных и воспроизводить проблемы, возникающие в процессе работы машин, с учетом их настроек (т. е.
реализации цифрового двойника).
В настоящее время в представленной структуре разрабатываются и тестируются собственные решения уровней IoTHub, CNCHub и CNCIoTCloud на основе взаимодействия с системой управления AxiOMA, системой управления обрабатывающим центром С7106MF4, а также стендовыми образцами других систем ЧПУ.
(Фанук, Сименс, Фагор).
Быстрая настройка возможна через Интернет или мобильное приложение.
На рисунке 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, которые проявляются при построении сложных аналитических выборок и агрегаций.
На данный момент сотни миллионов строк для таблиц в реляционных базах данных — это не предел, однако для организации эффективного и отказоустойчивого хранилища в реляционной модели необходимо использовать механизмы репликации и шардинга (горизонтального масштабирования).
Ввод в эксплуатацию устройств промышленного Интернета вещей приводит к нелинейному увеличению генерации данных в хранилищах.
Это связано с тем, что значительная часть процессов анализа и воспроизведения требует высокой частоты опроса полевых устройств.
В данной работе в качестве основного хранилища оперативной информации от технологического оборудования была принята реляционная база данных с открытым исходным кодом PostgreSQL. Понятие «узел» представлено как базовая сущность, как единица агрегации устройств внутри процесса.
«Узлом» может быть либо один датчик, либо комбинация систем управления и промышленных устройств Интернета вещей, что обеспечивает контекстно-зависимое хранение данных.
Особенностью устройств промышленного Интернета вещей внутри контекста является разная частота опроса с устройств полевого уровня и время актуальности собранных данных.
Например, в рамках процесса датчики, работающие в сети LoRaWAN (максимальная скорость передачи 50 кбит/сек), устройства, взаимодействующие через REST API (в зависимости от установленной политики устройства и Backend Rate Limiting принимающего сервиса) и OPC UA ( частота опроса на уровне поля 50 мс).
Чтобы обеспечить безопасность данных и отдельные политики доступа к системе, необходимо реализовать механизм регистрации устройств.
В настоящее время платформа служит для сбора информации и не инициирует запросы, поэтому политика безопасности ограничивается регистрацией устройств.
Предлагаемая в работе архитектура требует реализации контракта между сетевым устройством и веб-сервисами разрабатываемой платформы.
В качестве базового синтаксиса использовался универсальный текстовый формат JSON с рядом синтаксических ограничений на обязательность некоторых атрибутов.
В качестве важных параметров выделены: идентификатор устройства, группа запросов и ожидаемый формат данных.
Группа запросов представляет собой отдельный объект и позволяет отслеживать такие устройства, как системы числового программного управления, которые отправляют в запросе самые разнообразные данные (например, показания отдельных осей или внутренние коды ошибок).
Формат не допускает вложенных структур.
Вложенность структур в предлагаемую платформу будет означать согласованность данных и ошибки при построении аналитических отчетов и представлений.
Однако ошибочные запросы к сервисам возможны из-за большого разнообразия устройств и фиксируются по мере поступления для последующей корректировки и агрегации в рамках инициированного процесса.
В случаях нарушения контракта веб-службы уведомляют устройство соответствующим HTTP-кодом и регистрируют проблемные вызовы соответствующего устройства на стороне платформы.
Превышение заданного количества допустимых потерь и статусов ошибок запускает процесс уведомления (от лат. notificare — оповещать) заинтересованных устройств.
Теги: #iot #Промышленное программирование #индустрия
-
Затраты, Связанные С Магазином Приложений
19 Oct, 24 -
Зайцеобразные
19 Oct, 24 -
Reactos 0.4.7: Павел Дуров Больше Не Пуйщн
19 Oct, 24 -
Как Развивать Идеи
19 Oct, 24 -
Как Я Писал Классические Танки С Интеллектом
19 Oct, 24
