Практический пример: Первые шаги в направлении IIoT в среде МСП

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

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

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

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

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

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

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

ИТ-среда клиента

ИТ-среда клиента сформировалась естественным образом и поэтому является по своей сути сложной. В ее основе лежит устаревшая система 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, который становится все более распространенным в современных ПЛК и машинах. Хотя этот стандарт может использоваться для установления связи в реальном времени и, следовательно, заменить функции, которые в настоящее время реализуются промышленными системами полевой шины, в нашем сценарии возможности реального времени не требуются. Хотя для прямой интеграции стека OPC UA в приложение моего клиента доступны SDK, они обычно сложны и, таким образом, противоречат цели снижения сложности.

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

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

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

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

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

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

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

ПЛК робота,

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

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

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

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

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

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

Периоды работы, потребляемая мощность, …

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

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

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

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

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

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

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

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

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

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

Заключение

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

О Ричарде Мажере

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