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

Партнер Новости компании, Разъемы, Общие сведения Оставить комментарий

IIoT и Industry 4.0 - это вездесущие темы в современных отраслевых выставках и блогах. Многие продукты обещают помочь вам достичь вертикальной интеграции производственного потока и данных, а также корпоративного программного обеспечения, такого как ERP. Но, как правило, есть и подвох: либо вы получаете очень сложные продукты с таким же шокирующим ценником - или несмотря на МИОТ обещание полной кросс-вендорской совместимости вы обратитесь заблокированный поставщикомособенно если вы рассматриваете программные решения, которые продаются поставщиками производственного оборудования вместе с их оборудованием.  

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

В данном случае, я хотел бы показать, как Connecting Software интеграционная платформа Connect Bridge помогает заполнить этот пробел и обеспечивает простой в использовании набор инструментов для быстрого начала разработки пользовательских IIoT решения.  

О клиенте и его требованиях

Клиент небольшой отраслевой поставщик, который поставляет в основном изделия из нержавеющей стали. с небольшими партиями (до одной) и сложным ассортиментом продукции.  

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

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

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

Требования короче говоря: 

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

ИТ-среда заказчика

IT-ландшафт заказчика является естественным и, следовательно, по своей природе сложным. В его основе лежит унаследованная ERP-система, дополненная пользовательскими веб-приложениями PHP и интерфейсами к другим программным продуктам (например, CAD, CAM, например, программное обеспечение для лазерного раскроя, ...), а также клиентскими системами для прямого обмена данными. Все это в смешанной серверной среде Windows/Linux и почти исключительно клиентском пуле на базе Windows в Active Directory. Файловые службы основаны преимущественно на общих папках Windows и (в меньшей степени) на Dropbox.  

При постоянном переходе на Microsoft Windows 10 и Office 365 такие темы, как внедрение SharePoint или OneDrive в IT-процессы компании могут представлять интерес.   

В целом, стратегия заказчиков заключается в снижении сложности своей ИТ-инфраструктуры, стараясь уменьшить количество используемых различных технологий (LAMP-стеков, AD, Windows, O365, устаревших систем и т.д.), тем самым повышая управляемость и снижая затраты на обслуживание всей экосистемы.

Производственная среда

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

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

Компоненты этой системы обмениваются данными через различные стандартные промышленные соединения (цифровые входы/выходы), Профинет, EtherCatстандартный ethernet). По спецификациям производителя только один стандартный интерфейс ethernet подвергается воздействию на сетевую инфраструктуру заказчика. Этот интерфейс подключается к общей системе ПЛК производителей машин и обеспечивает лишь очень ограниченный доступ к данным машин и системе управления. Он предлагает интерфейс OPC UA с очень небольшим количеством точек данных (менее 10). И они заполняются только в том случае, если на заводе-изготовителе используется программное обеспечение для планирования производства, запущенное на ПЛК машины. Поэтому этот интерфейс оказался не слишком полезным для моего заказчика. Эта ситуация может измениться. Однако, так как этот открытый интерфейс OPC UA находится в процессе разработки, он, вероятно, получит более полезные возможности при будущих обновлениях. 

Но так как многие подкомпоненты машин используют стандартную сеть ethernet в качестве способа связи, возможен больший доступ. Внутри станков доступны ПЛК робота, лазерный источник и система камер сварочных головок. Но без дальнейшей модификации не все из них предлагают необходимые инструменты для обеспечения легкого доступа OPC UA.  

Первые шаги

В качестве первого шага ставилась цель получить данные непосредственно от компонентов машины.  

Прямое управление этими системами через Connect Bridge (CB) не является мишенью, так как потенциально может нарушить принцип единой точки управления, необходимый для безопасности машины.  CB предоставляет простой в использовании интерфейс к стандарту OPC UA, который все чаще встречается в современных ПЛК и машинах. Хотя этот стандарт может быть использован для установления связи в реальном времени и, следовательно, заменить функции, которые в настоящее время реализуются промышленными системами полевой шины, в нашем сценарии возможности реального времени не являются необходимыми. Несмотря на то, что SDK доступны для прямой интеграции стека OPC UA в приложение моего заказчика, они, как правило, сложны и, таким образом, противоречат цели снижения сложности.  

Поэтому выбор пал на Connect Bridge с его преимуществами простая настройка, удобный SQL основанный на интерфейсе не только с OPC UA, но и с другими локальными и облачными сервисами, и чрезвычайно конкурентоспособная цена

Периодичность опроса данных

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

Таким образом, довольно низкая частота опроса 30 секунд в настоящее время используется для сбора данных.  

На этом первом этапе клиент хочет опросить данные из этих 3-х основных компонентов:  

  • лазерный источник, 
  • ПЛК робота,
  • система камер. 

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

Почему робот ПЛК не может подключить

Доступ к ПЛК робота осуществляется через ethernet, но при этом используется устаревший OPC-интерфейс. Из-за программных ограничений его производителя, он не может работать с OPC UA. Интерфейс OPC - OPC UA мог бы спасти эту ситуацию, но без зелёного света от производителя машины с точки зрения совместимости установка такого программного обеспечения не представлялась возможной. На данный моментКлиент разрабатывает обходной путь: цифровые операции ввода-вывода робота будут подключены через промышленный ПК, чтобы получить точную информацию (например, когда производственный процесс был начат или закончен) и запустить более узкое окно сбора данных.  

Почему камера не может подключиться

Система камеры привязана ко всему ПЛК машины и, кажется, не доступна сторонним клиентам. Так как видение было бы полезно для целей контроля качества и документации процесса, использование дополнительной, внешней системы камер в настоящее время оценивается для решения этой проблемы.

OPC UA для лазерного источника

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

Этот интерфейс предлагает множество данных:  

  • Общее состояние лазерной системы
  • Периоды эксплуатации, потребляемая мощность, ...
  • Сообщения об ошибках и обслуживании

С CB, клиент разработал Windows сервис в C#, чтобы периодически опрашивать данные и компилировать их в несколько таблиц базы данных SQL для дальнейшего использования. В таблицах может содержаться такая информация, как общие данные, использование оборудования, таблицы для сообщений об обслуживании/ошибках, выдаваемых лазерным источником.  

Но как применить эти данные? 

Большой вопрос: как использовать данные о машинах

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

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

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

  • Подключение к ПЛК робота (через цифровые входы/выходы, если это невозможно) для получения точного времени запуска/остановки производственных циклов. 

В сочетании с системой учета рабочего времени на предприятии это позволит лучше понять, сколько времени занимает машина на самом деле производство и сколько времени уходит на обучение (программирование роботов) и/или погрузку/разгрузку/обслуживание; 

  • Доступ к камере системы: так как лазерная сварка является другим процессом сварки, клиенты моего клиента должны сертифицировать этот метод производства, прежде чем любые реальные продукты будут доставлены. Такие процессы будут гораздо проще достичь, если полная документация по процессу сварки будет поставляться постоянно и автоматически. 

Кроме того, в связи с планируемым снижением сложности и количества используемых сервисов, переход с Dropbox-Shared на OneDrive неизбежен, как только он будет внедрен на всех заинтересованных клиентах. Заказчик также заинтересован в возможном анализе данных для прогнозирования технического обслуживания. 

Заключение

Как было написано выше, этот проект находится в фазе пристального внимания и еще далек от того, чтобы быть полностью функциональным IIoT решением. Но с небольшими первоначальными усилиями можно было бы разработать полезный демонстратор для заказчика с использованием мощные возможности 1ТП16Т. Как разработчик, это помогло мне, избежав необходимости вникать в детали еще одного стека соединений. (как OPC UA или Dropbox API). И для моего клиента он предоставил централизованный стек связи для будущих приложений, которые также очень конкурентоспособны по цене по сравнению с решениями других производителей, которые иногда имеют сложные настройки лицензирования с лицензиями, основанными на количестве устройств, к которым обращается его инструмент, и даже количество полученных точек данных. 

используемые сокращения

СВ - 1ТП16Т платформа интеграции

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

IIoT - Промышленный Интернет вещей 

OPC UA - OPC Unified Architecture 

CAD - автоматизированное проектирование 

CAM - автоматизированное производство 

Справочная информация

В данном тематическом исследовании анализируется применение протокола OPC UA для сбора актуальных данных о машинах на небольшом производственном объекте в Австрии. OPC UA-разъём построенный на интеграционная платформа Connect Bridge по адресу Connecting Software был использован для вытягивания данных о машинах в таблицы отчетов для своевременного технического обслуживания оборудования на производстве. Платформа интеграции принимает простые SQL-запросы Create, Read, Update and Delete (CRUD) через стандартные драйверы ODBC, JDBC и Web Services. Эти запросы транслируются в стандартные вызовы API, соответствующие целевой системе. Ряд предварительно созданных разъемов позволяет доставлять эти данные в ERP, MES, CRM, DMS системы и т.д. для дальнейшего использования. 

Об авторе

Ричард Майер, Основатель flupo Systemtechnik e.U. Специализируется на промышленных ИТ и технологиях автоматизации для малого и среднего бизнеса. Прежде чем основать собственную компанию, Ричард работал в научно-исследовательском институте по применению мощных лазеров (приобретая опыт в области лазерных технологий, моделирования FEM, промышленной робототехники, программирования ПЛК, промышленных систем полевой шины), а также имеет более чем 10-летний опыт работы в области информационных технологий в целом с акцентом на разработку программного обеспечения в средах МСП (интерфейсы между различными программными продуктами, приложения для планирования производства). Он владеет магистр диплом по математике Венского университета 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *