Умное управление и ПО HMI: расширение возможностей инженеров для построения сетей IIoT нового поколения

Марисса Такер из Parker Hannifin беседует со старшим редактором Патриком Ваурзыняком

Марисса, какова роль контроллера движения в промышленном интернете вещей [IIoT], и какое ПО задействовано?

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

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

Обеспечение того, чтобы разработчик, создающий встроенный HMI, мог создавать разные группы пользователей и учетные данные, критично. Это позволяет программисту создавать пользовательский экземпляр HMI в зависимости от пользователя.

Легкость потока информации внутри станка важна, но также важна легкость потока информации между станками. Стандарт программирования IEC 61131-3 гарантирует, что станок, разработанный одним производителем, говорит на том же языке, что используется другим. Это сильно выгодно интеграторам, потому что они могут легче заставить две разные машинные системы говорить друг с другом, необходимый шаг к IIoT. Организации вроде OMAC [Организация для автоматизации и управления станками], которая продвигает стандарт PackML, выносят IEC 61131-3 на следующий уровень, не только рекомендуя, как система должна быть запрограммирована, но и разрабатывая стандартный набор тегов, которые станки должны делать доступными для других станков в сети.

А как же низкоуровневые устройства, такие как пневматические клапаны и датчики положения? Разве всё не должно быть частью IoT?

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

Оставляя шину простой, эти данные могут быть собраны и сделаны полезными обработкой на PAC или ПЛК, который должен существовать в каждой машинной системе. Переходя на PAC, который также имеет встроенный HMI для веб-публикации, пользователи могут затем взять эту информацию и положить её в сеть, куда бы она ни должна пойти. Представьте пневматическую систему с датчиком, непрерывно мониторящей звук в децибелах. Единственные данные, которые нужно отправить в PAC IO-Link — это текущие дБ. PAC может иметь пользовательские функциональные блоки IEC 61131-3, разработанные производителем, которые могут работать на нескольких контроллерах. Эти функциональные блоки могут проверять, есть ли странный паттерн в шуме, чтобы сказать: «Ага, может быть утечка». Программист может взять это оповещение и отправить сообщение пользователю уровня обслуживания HMI до того, как пневматика выйдет из строя.

Как информация попадает от станка в облако, и как насчет задействованного ПО?

Все еще есть большой разрыв между заводским полом и IT. Особенно для производственных компаний с несколькими объектами в разных штатах или странах, хранение данных во внешнем сервере или облаке идеально. С стороны программного обеспечения, производители компонентов должны помогать сделать жизнь конструкторов станков максимально легкой при работе с IT.

Большинство конструкторов станков комфортно программируют ПЛК или PAC на IEC или похожих языках, поэтому компании должны искать производителей, которые принимают интегрированный подход к управлению станком, чтобы сделать поток информации легким, но которые также делают легким обмен этой информацией с IT-серверами. Еще один стандарт, вытекающий из Европы — OPC-UA [OPC Unified Architecture]. Этот клиент-серверный протокол значительно расширился, позволяя универсальный способ передачи данных либо станок-станок, станок-SCADA, или станок-сервер. Благодаря своей гибкости, OPC-UA быстро становится стандартом IoT. Ищите поставщиков, у которых есть встроенные программные инструменты для легкого создания OPC-UA соединения за пару кликов и позволяющие разработчикам делиться данными просто путем обмена несколькими тегами в программе IEC 61131-3. Как только это доступно на сервере, пусть IT заботится об остальном.

Полезна ли информация в облаке? Как критические данные попадают в руки оператора на заводском полу?

Это зависит от варианта использования. Любой, думающий о IIoT, будь то оператор станка, OEM-производитель станков или владелец завода, должен сначала разработать вариант использования. Менеджер заводского пола, например, может захотеть информацию об общей эффективности оборудования [OEE]. Этот тип информации обычно не тот, которым стоит делиться с более широкой публичной сферой, поэтому лучше использовать внутренний сервер. Однако менеджеры заводского пола часто могут быть далеко от станка или не за своими столами, но все равно должны смотреть на OEE. Вариант использования управляет решением: если у станка есть встроенный HMI с веб-сервером, пользователь может подключиться к нему с iOS или Android платформы, ввести свои учетные данные и посмотреть OEE станков, внешнее облако не нужно. Эта внутризаводская сеть часто называется «туманными» вычислениями (fog computing).

Другой пример — закупочный агент, которому нужно мониторить данные выхода для нескольких заводских линий в нескольких местах. Внешний сервер — единственный ответ. Чтобы минимизировать риск раскрытия конфиденциальной информации компании, программа может публиковать только общий выход, а не выходы. Хотя это решение требует использования облачного сервера, оно иллюстрирует необходимость сдерживания при отправке любых данных на внешний сервер по двум причинам: обычно это менее безопасно, чем хранение во внутренней или «туманной» сети, и большинство тарифов взимают плату за отправку и хранение данных во внешнем облаке.

Маркетологи отлично поработали над продвижением Индустрии 4.0, но каждый пользователь должен отстраниться и спросить: «Как я могу использовать информацию?» Облако может быть не так необходимо, как вы могли подумать.

Разве все эта связность не повышает затраты?

Может, но не обязательно. Там, где становится дорого — через три или четыре года в будущем, когда ваша компания готова к IoT, но вы специфицировали устройства, которые делают трудным или невозможным общение через веб-сервер или OPC-UA, или вы выбрали традиционный фрагментированный дизайн вместо односторонних PAC, которые делают поток данных значительно легче. Чтобы смягчить эту ошибку, вы можете купить невероятно дорогие датчики, которые идут от контроля температуры прямо во внешнее облако, обходя все остальные устройства на станке. Оттуда вам придется программировать целый настраиваемый слой или веб-сайт, используя чужое ПО, чтобы сделать данные полезными. Вы не хотите быть этим парнем.

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

Также выбирайте низкоуровневые устройства, поддерживающие шины вроде IO-Link, чтобы вы могли получать данные из них доступно. Используйте стандартные протоколы, которые являются экономически эффективными и позволяют использовать данные из множества источников. Используйте единое программное обеспечение программирования на едином контроллере для упрощения программирования. Убедитесь, что контроллер станка имеет способность для клиент-серверных отношений без необходимости дополнительного шлюза. Таким образом, если вам понадобится начать маршрутизацию информации в разные места, вы сможете сделать это прямо в вашей программе на базе IEC. Не забывайте про туманные вычисления. Если у вашего ПЛК есть встроенный HMI с возможностями веб-сервера, вы можете удовлетворить все ваши варианты использования IIoT без использования облака вовсе. И если вам понадобится, убедитесь, что выбранный контроллер имеет ПО, которое делает легко обмен данными с OPC-UA сервером, чтобы IT мог делать то, что IT делает лучше всего.

Умные выборы делают переход к IIoT очень доступным, но выборы нужно сделать сейчас.