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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первые шаги

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

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

Поэтому вместо индивидуального кодирования клиент выбирает интеграционную платформу, которая имеет готовый коннектор OPC UA с простым в использовании интерфейсом и возможностью подключения к таким офисным системам, как ERP, CRM, различным системам документооборота или базам данных - локальным и облачным, а также разумную цену.

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

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

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

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

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

лазерный источник,

ПЛК робота,

система камер.

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

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

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

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

Общее состояние лазерной системы

Периоды эксплуатации, потребляемая мощность, ...

Сообщения об ошибках и обслуживании

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

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

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

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

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

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

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

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

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

Заключение

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

О том, как Ричард Майер

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