Open Platform Communications United Architecture (OPC UA) – это стандарт обмена данными, используемый в промышленной автоматизации и связи. OPC UA – это независимый стандарт, не связанный с конкретной системой или производителем, он осуществляет связь посредством связи компьютер-машина или связи машина-машина. Предлагаем статью инженера Энтони Кинг Хо, опубликованную в журнале Control Automation, посвященную истории, структуре и применении протокола OPC UA.

История создания OPC UA

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

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

В результате сообщество OPC Foundation разработало первую спецификацию для OPC DA, Data Access Specification 1.0a. Она была выпущена вскоре после этого, в начале 1996 года. Стандарт Data Access Specification определяет, как должны быть построены интерфейсы клиентского и серверного приложений. Используя эту спецификацию, поставщики могли быстро разрабатывать клиентское/серверное программное обеспечение.

Как работает OPC UA?

Однако, поскольку OPC DA в значительной степени опирается на Windows Distributed Component Object Model (DCOM), многие поставщики признают, что OPC DA не является по-настоящему открытым стандартом, плохо ведет себя в отключенном состоянии, плохо работает с брандмауэрами и работает только в Windows.

Чтобы преодолеть недостатки OPC DA, OPC Foundation разработал OPC UA, который значительно отличался от своего предшественника. Цель состояла в том, чтобы отойти от использования Windows DCOM в основном для лучшего удовлетворения меняющихся потребностей промышленной автоматизации.

Первая спецификация OPC UA была опубликована в 2006 году, а последняя версия, 1.04, была выпущена в ноябре 2017 года, добавив инфраструктуру связи публикации/подписки и новые политики безопасности.

Некоторые из улучшений, которые были введены в OPC UA, включают:

• Открытость – доступен для использования и внедрения любым пользователем по лицензии GPL 2.0;

• Кроссплатформенность – не привязан к одной операционной системе или языку программирования;

• Повышенная безопасность протокола – предоставляет пользователям доступ к аутентификации, авторизации, целостности и конфиденциальности;

• Введение метода, который представляет вызов функции объекта – метод вызывается (вызывается) и возвращается после завершения функции, независимо от того, была ли она успешной или нет;

• Интеграция информационной модели в IEC 62541 – эта спецификация является основой инфраструктуры, необходимой поставщикам для интеграции своей информации и моделирования своих сложных данных в пространстве имен OPC UA. Она использует преимущества богатой сервис-ориентированной архитектуры OPC UA.

  Структура OPC UA (IEC 62541)

  Расширения полей, указанные в инициативе Field Level Communication (FLC), основаны на структуре OPC UA (IEC 62541). Эта структура предоставляет поставщикам независимую платформу, которая обеспечивает безопасный и надежный обмен информацией.

Структура OPC UA поддерживает службы и протоколы клиент/сервер, а также модели и протоколы публикации/подписки (PubSub). OPC UA может работать на выделенных клиент/серверных отношениях. В сценарии PubSub сервер отправляет (публикует) данные в сеть, а клиент (подписавшийся) получает данные.

Важно отметить, что в спецификации OPC UA аутентификация, подписание и шифрование данных в значительной степени подчеркиваются как для моделей клиент/сервер, так и для моделей PubSub.

Роль OPC UA в промышленной автоматизации

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

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

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

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

С появлением Industry 4.0 разделение уровней и подход «сверху вниз» к потоку информации начали смешиваться, что означает, что в интеллектуальной сети каждое устройство или служба могут автономно инициировать связь с другими службами.

PLCopen (ассоциация производителей контроллеров на основе IEC 61131-3) сотрудничала с OPC Foundation для определения соответствующих функциональных блоков клиента OPC UA. Она создала способ для PLC обмениваться сложными структурами данных по горизонтали с другими контроллерами или по вертикали через сервер OPC UA в системе управления производством (MES) или планирования ресурсов предприятия (ERP) для получения новых производственных заказов или записи данных в облако. Эти усилия позволили производственной линии работать автономно в сочетании с интегрированной безопасностью OPC UA.

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

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

Industry 4.0 и OPC UA

Как упоминалось ранее, с Industry 4.0 и промышленным Интернетом вещей (IIoT) информация может свободно передаваться между различными устройствами в интеллектуальной сети. Это создало серьезную проблему для безопасного и стандартизированного обмена данными и информацией.

В 2015 году модель эталонной архитектуры для Industry 4.0 (RAMI 4.0) рекомендовала только стандарт IEC 62541 OPC UA для реализации уровня связи. В результате любой продукт, рекламируемый как «с поддержкой Industry 4.0», должен поддерживать OPC UA – интегрированный или через шлюз.

В модели клиент/сервер обычно используются TCP и HTTPS. В модели PubSub используются UDP, AMQP и MQTT.

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

Планы развития OPC UA

Транзакции

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

Метаданные в облаке

Когда данные публикуются в облачных приложениях, таких как Amazon Web Services (AWS) и Google Cloud, данные обычно не включают метаинформацию в адресном пространстве сервера. Метаданные помогут решить эту проблему в будущем.

Cloud Relay

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

Детерминированная связь

В текущем и прошлых поколениях связи связь не является детерминированной. С 5G, 5-м поколением беспроводных систем, она обеспечит лучшую производительность и детерминированность. Она будет похожа на Time Sensitive Networking (TSN), сопоставление модели PubSub с протоколом 5G сделает OPC UA более детерминированным.

Дополнительные сопоставления протоколов для детерминированной связи

В дополнение к 5G сопоставления с WiFi 6/7 могут сделать протокол детерминированным для беспроводных и мобильных промышленных приложений. Кроме того, сопоставление с сетевыми технологиями уровня 3 с поддержкой QoS (качество обслуживания) должно обеспечить детерминированную связь OPC UA, бесшовно маршрутизируемую по проводным и беспроводным сегментам сети.

Точно предсказать развитие OPC UA предсказать трудно, но похоже у данного протокола коммуникации есть большой потенциал.

Материал подготовлен Московским заводом тепловой автоматики (МЗТА)

Протокол OPC UA предназначен для решения двух задач автоматизации: взаимодействие между поставщиками устройств и решение проблемы несовместимости устройств на транспортном уровне. В статье Антонио Армента, опубликованной в журнале Control Automation рассматривается вопрос интеграции OPC UA и среды межмашинного взаимодействия –Machine-to-Machine.

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

Пирамидальная модель для интеграции автоматизации

Эффективный поток коммуникации между платформами, как по горизонтали, так и по вертикали, никогда не был столь важен. Этот тип связи чаще всего называют Machine-to-Machine – Межмашинное взаимодействие или M2M. Хотя название подразумевает физические машины, концепция M2M также применяется к интерфейсу между машинами и программными приложениями и даже между двумя или более программными платформами.

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

Что такое OPC UA?

Унифицированная архитектура открытых платформ связи называется OPC UA. Реализация этого промышленного протокола связи увеличивается как по масштабу, так и по сложности. Рассмотрим интеграцию M2M и OPC UA в разрезе задач промышленности.

Сеть OPC UA для различных отраслей промышленности

Достижение взаимодействия с OPC UA

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

Для решения этой проблемы OPC UA использует унифицированную модель данных (Unified Data Model – UDM), одну из своих самых мощных функций. Эта модель обеспечивает взаимодействие, предоставляя общую структуру для представления и передачи данных между несколькими платформами.

Что такое узел в OPC UA?

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

NodeId: уникальный идентификатор.
DisplayName: читаемое имя для упрощения просмотра.
DataType: логическое, целое число, строка и т. д.
Value: текущие данные или статус, хранящиеся в узле.

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

HasSubType: устанавливает вертикальные иерархии между узлами.
HasCause и HasEffect: устанавливает причинно-следственную связь. Это очень полезно для устранения неисправностей.
HasInterface: помогает реализовать стандартные интерфейсы связи, такие как TCP/IP.
HasProperty: связывает узлы с узлами свойств.

OPC UA поддерживает все известные типы данных, включая целые числа, строки, массивы и сложные структуры. Также поддерживаются пользовательские типы данных, что позволяет представлять абстрактные составные структуры.

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

Независимость транспортного уровня

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

Некоторые протоколы связи, поддерживаемые OPC UA, включают TCP/IP, HTTP и HTTPS, MQTT (очень распространенный в приложениях Интернета вещей – IoT) и множество заводских протоколов на основе Ethernet.

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

Использование OPC UA для интеграции устаревших систем

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

Таким образом, OPC UA способствует обеспечению взаимодействия, повышению эффективности работы, обеспечению масштабируемости в будущем и устранению изолированности данных.

Материал подготовлен Московским заводом тепловой автоматики (МЗТА)

Добавляем Конфигурацию тревог.

Error, Info, Warning - это у нас классы, где мы настраиваем цвет сработанной аварии, цвет квитирования и цвет отмеченной аварии. и, соответственно шрифт текста.

AlarmStorage - это настройки хранилища, где будем архивировать аварии.

После этого добавляем группу тревог и список сообщений.

Получаем вот такой список элементов.

Настройки Конфигуратора и вывод на экран

Настраиваем классы аварий, цвет, шрифт, действия, способ квитирования.

В списке текстов пишем названия сообщений - под каждую переменную своё название. ID - это номер строки.

Дальше настраиваем группы аварий, каждая со своей переменной, сообщением и способом квитирования.

Вот так выглядит сама настройка. Можно выбрать разные способы наблюдений.

Можно по дискретному сигналу, можно по верхней и нижней границе, можно за пределы, можно посередине, можно по изменению, можно по событию. Логика настраивается.

Далее добавляем визуализацию, либо баннер либо таблицу.

Мне удобнее всего в виде таблицы. Её можно очень гибко настроить. Шапку, столбцы, толщина столбца, шрифт ну и т.п.

Можно сделать несколько групп и разные аварии, можно делать сообщения и аварии в отдельных таблицах. Кому как надо.

Это готовые кнопки управления панелью алармов.

Вот так выглядит в одном из рабочих проектов. Там требовалось сделать просто сообщения.
Пишите комменты, как делаете вы?

• CU: вход счётчика с увеличением, тип данных bool. Каждое изменение CU увеличивает счётчик на 1.

• Reset: вход сброса счётчика. Когда Reset равен «истина», счётчик сбрасывается.

• PV: установленное значение счётчика. Максимальное значение счётчика для подсчёта битов.

Выходы счётчика:

• Q: выходной бит счётчика. Состояние Q становится «истина», когда текущее значение счётчика (CV) равно или больше установленного значения.

• CV: выход счётчика. Это текущее значение счётчика.

Выше приведен пример счётчика с увеличением в ПЛК. Каждый нарастающий фронт CU увеличивает счётчик на 1. Когда значение счётчика (CV) равно или больше установленного значения, выход счётчика (Q) включается. Счётчик с увеличением сбрасывает текущее значение (CV) до нуля, если вход сброса счётчика включен. Текущее значение счётчика продолжает увеличиваться, даже если выход счётчика равен «истина».

Счётчик с уменьшением (Down Counter) CTD в ПЛК

CTD — это счётчик с уменьшением в ПЛК. При каждом нарастающем фронте счётчика с уменьшением значение счётчика уменьшается на 1. При инициализации счётчика или первом запуске установленное значение счётчика не задаётся, пока вход загрузки не станет «ложь», поэтому установите вход загрузки в «истина», чтобы задать установленное значение. Когда вход загрузки включен, установленное значение счётчика задаётся, и каждое изменение входа счётчика уменьшает значение счётчика на 1. Ниже приведены входы и выходы счётчика с уменьшением:

Входы счётчика с уменьшением:

• CD: вход счётчика с уменьшением, тип данных bool. Каждое изменение CD уменьшает счётчик на 1.

• LOAD: когда LOAD установлен в «истина», устанавливается предустановленное значение счётчика. В противном случае счётчик не уменьшается.

• PV: установленное значение счётчика. Установленное значение счётчика задаётся, когда LOAD равен «истина».

Выходы счётчика:

• Q: выходной бит счётчика. Состояние Q становится «истина», когда текущее значение счётчика (CV) равно нулю.

• CV: выход счётчика. Это текущее значение счётчика.

Выше приведен пример счётчика с уменьшением в ПЛК. Установите LOAD в «истина», чтобы установить предустановленное значение счётчика, затем установите LOAD в «ложь». Если LOAD равен «истина» и вход счётчика (CD) изменяется с «ложь» на «истина», то текущее значение счётчика остаётся неизменным, поэтому всегда устанавливайте значение LOAD в «ложь», если установлено предустановленное значение счётчика.

Если значение счётчика установлено и вход LOAD равен «ложь», то каждый нарастающий фронт входа CD счётчика уменьшает значение CV счётчика на 1 до тех пор, пока значение счётчика не достигнет нуля. Как только значение счётчика становится равным нулю, выход счётчика Q устанавливается в «истина».

Реверсивный счётчик (Up/Down Counter) CTUD в ПЛК

CTUD — это инструкция реверсивного счётчика в ПЛК. CTUD работает как счётчик с увеличением и уменьшением при выборе соответствующего входа CTUD. Для счётчика с увеличением CU устанавливается в «истина», а все остальные битовые входы устанавливаются в «ложь».

Для счётчика с уменьшением бит CD включается и устанавливается предустановленное значение. CTUD — это комбинация счётчика с увеличением и уменьшением, он работает как счётчик вверх или вниз. Каждый нарастающий фронт входа CU увеличивает счётчик на 1, а каждый нарастающий фронт CD уменьшает значение счётчика на 1.

Выше приведен пример реверсивного счётчика в ПЛК. Все входы и выходы представляют собой комбинацию входов и выходов счётчика с увеличением и уменьшением. Реверсивный счётчик работает как счётчик с увеличением, если CD, LOAD, Reset установлены в «ложь», и вход счётчика CU изменяется с «ложь» на «истина», то счётчик увеличивает значение на 1. QU — это выход счётчика с увеличением, он устанавливается, когда счётчик (CV) больше установленного значения счётчика.

Реверсивный счётчик работает как счётчик с уменьшением, когда CU, RESET и LOAD равны «ложь», и установлено предустановленное значение или текущее значение счётчика больше нуля. Каждый нарастающий фронт уменьшает значение счётчика на 1. QD — это выход счётчика с уменьшением, он включается, когда текущее значение счётчика равно нулю.