Opc

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 способствует обеспечению взаимодействия, повышению эффективности работы, обеспечению масштабируемости в будущем и устранению изолированности данных.

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

Добавляем узел и ставим настройку OwenCloud.

Нажимаем ПКМ Добавляем устройство. Вводим логин и пароль вашего аккаунта.

Сервер автоматически найдёт токен и спросит, что нужно добавить. выделяем все необходимые каталоги и теги.

Это реальный рабочий объект. Здесь мы можем запустить опрос и получать данные с Облака. Можем выключить или включить необходимые теги.

Вот здесь мы получаем реальное значение Температуры в теплице. И дальше мы можем делать всё, что захотим — передавать в SCADA или в другое устройство. Всё.

SCADA + OPC + Облако

У меня стоит программа MasterSCADA можно в ней получить значения и работать с ними далее.

Создаем новый проект.

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

Выбираем наш ОРС-сервер.

Добавляем все необходимые теги для мониторинга и анализа.

Вот такая получается картина, нажимаем кнопку «Запуск».

Вот мы получаем наши показания температуры. Нужно понимать, что скорость опроса очень сильно страдает. Если у вас базовый тариф, то будет 1 минута Облако + 30 сек ОРС + 30 сек примерно MS. Все времена настраиваемые, но всё равно 1 минута минимум. Не для всех это подойдет.

На этом я всё.

Если есть вопросы, пишите в комментариях. Чтобы ответы были доступны для всех желающих.

С уважением, Гридин Семен.

Кстати можно сделать тоже самое но в Excel:

Я работаю инженером АСУТП и немного увлекаюсь программированием: при помощи Гугла и Stack Overflow делал несколько калькуляторов на HTML и javascript, делал бота для телеграма на php, даже немного программировал на C# по работе. В этот раз задача была куда интереснее и сложнее, хотя и звучала просто: «хочу видеть в своем браузере текущую скорость агрегата». Для начала я решил попробовать поискать готовый софт: естественно такое уже давно придумано, есть готовые и даже бесплатные SCADA системы, которые могут работать и в качестве веб сервера, но они все были сильно наворочены и сложны для моего понимания, к тому же нужно было просто вывести скорость. Поэтому я подумал что можно попробовать сделать это самому и вот что из этого вышло:

Backend

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

Поиски этого привели меня на хабр, где я узнал про бесплатную библиотеку OPCDOTNET. В архиве библиотеки лежал исходник консольного клиента, который я скомпилировал на своем компьютере, запустил простой OPC симулятор (gray-box)… и о чудо! я увидел в консоли изменяющиеся числа. Это значит, что теперь я смогу их отправлять в качестве ответа по вебзапросу. Следующим заходом в гугл стал запрос простого веб сервера где наткнулся на пример использования HttpListener. Запустил пример в отдельном проекте, понял как это работает, и стал добавлять все это к своему OPC клиенту. Через много попыток компиляций, поиска ошибок на Stack Overflow у меня все же получилось увидеть в браузере заветную «скорость». Это была победа! Но я сразу же понял, что одна лишь скорость это не серьезно, через время технологи захотят увидеть и другие параметры линии, поэтому нужно придумать как добавлять необходимые сигналы, без изменения программы. На помощь пришли файлы конфигурации, где можно заранее задать какие сигналы хотим видеть, задать порт прослушивания сервера, время обновления и прочее. Опыт в создании файлов конфигурации уже имелся, поэтому сделал так как ранее делал и проверенно работало. Так же в процессе пришлось обратиться к другу программисту, который подсказал что сделать чтобы передавался полный массив запрашиваемых данных, а не только те значения что менялись (в готовом примере OPC клиента в консоли отображались только изменяемые значения).

После таких изменений программа стала генерировать таблицу в HTML из запрашиваемых в конфиге сигналов: обратившись через браузер по адресу сервера, где был запущен этот клиент, теперь можно было видеть таблицу, в которой были названия сигналов и значения в соседнем столбце. Это было уже неплохо, но значения при обновлении промаргивали, а сами сигналы тупо располагались друг за другом хоть и были структурированы в виде таблицы. Кстати, чтобы значения обновлялись автоматически ежесекундно, а не только когда пользователь обновит страницу, я добавил в возвращаемую на запрос страницу тег meta с параметром Refresh. Но мне очень хотелось чтобы значения обновлялись автоматически и без перезагрузки страницы, поэтому нужно было кроме бэкенда теперь делать и фронт: пользователь запрашивает страницу на сервере, внутри которой происходит запрос к клиенту, и страница после этого генерирует все это в красивом и понятном виде, где можно структурировать данные как заблагорассудится, поменять цвета, шрифты и размеры — сделать можно вообще все что угодно при таком-то подходе. Полный код клиента под винду на C# есть на гитхабе https://github.com/boolkin/opc2web-client

Frontend

Пришел я к этому не сразу: сначала стал гуглить как сделать так чтобы данные на странице обновлялись без перезагрузки. Как выяснилось нужно использовать AJAX, то есть изменять данные через javascript, а принимать их через JSON. В клиенте простой конкатенацией строк сделал генерацию JSON, причем для универсальности решил просто отсчитывать по порядку задаваемые в конфиге теги. Потом нашел пример в котором через javascript запрашивается ежесекундно JSON строка и выводятся значения из нее. Поменяв код под свои нужды и запустив страницу я увидел что все работает — данные обновляются без перезагрузки страницы (!). Это была еще одна победа. Теперь оставалось дело за малым — грамотно распределить на странице полученные данные, то есть сделать что-то в виде визуализации. Сначала я решил сделать так же таблицу, но потом понял что блочная структура смотрится красивее и функциональнее. Блоки можно окрашивать в разные цвета и менять их размер. А еще нужно сделать так чтобы пользователь мог самостоятельно добавлять и изменять структуру, не буду же я на каждую новую хотелку переписывать HTML файл. В итоге получился такой вот вариант, как на картинке ниже.

Здесь можно добавлять большие блоки, которые будут объединять малые блоки с одним признаком. Такие большие блоки можно озаглавливать так как нужно, менять их цвета (если щелкнуть по блоку с зажатой клавишей shift) и менять их размер. Блоки со значениями добавляются при двойном клике по большому блоку. В них так же можно задавать свои названия и единицы измерения. Если нечаянно добавил не тот элемент или не туда, то можно удалить его — я подсмотрел эту функцию в одном букмарклете, полностью перенеся его код на страницу. Конечно вся созданная структура после перезагрузки страницы исчезнет и для ее сохранения нашел такую возможность как локальное хранилище. А для того чтобы перенести готовую структуру на другой компьютер сделал импорт и экспорт экрана из локального хранилища.

Единственная проблема оставалась с перетаскиванием блоков — хотелось бы сделать красиво drag and drop, но для меня это оказалось непосильно. Вышел из ситуации так: если открыть страницу в панели разработчика в хроме, то блоки можно перетаскивать. Это натолкнуло на мысль что задействовав правую кнопку мыши можно просто менять блоки местами. Сейчас такая система вполне универсальная: чтобы добавить новый сигнал нужно просто добавить нужный OPC тег в конфиг и перезапустить клиента. Добавленный тег автоматически добавляется в JSON и на экране вывода появляется внизу новое значение, которое можно несколькими кликами добавить в существующий или новый блок на странице. На данный момент на странице выводится больше 60 тегов и больше половины из них добавлял уже не я, то есть процесс добавления может и не самый простой, но не требует переписывания программы и страницы вывода. Протестировать и посмотреть код этой страницы можно тут на github opc2web html В этой версии добавлено специальное меню для манипуляций с блоками, и есть даже подобие HMI с использованием svg формата, вот как это выглядит на картинке.

Заключение

Поскольку данная статья должна быть вроде инструкции, как непрограммист вроде меня с помощью поисковиков может сделать что-то полезное, то наверное нужно добавить немного слов о том как именно я искал информацию. Тут впору говорить как на картинке в самом начале: думаешь что ты хочешь получить и спрашиваешь об этому у гугла, а если что-то где-то не получается, то смотришь на коды ошибок и спрашиваешь снова. Очень помогает поиск на английском языке — даже вбив просто ключевые слова можно получить ссылку на подобную решенную проблему на стаковерфлоу с вероятностью 80%. Для поиска готовых примеров, код из которого можно тупо взять и перенести в свою программу, можно добавлять такие ключевые слова как «example» или по-русски «пример». Несколько хороших идей нашлось на хабре, то есть можно попробовать в запрос вставить ключевое слово «habr», но я таким пользовался только тогда когда точно знал что на хабре видел решение которое ищу. Практически любая мелкая задача из всего того, что было сделано, решалась через поисковик: «change div color shift click js», «make div resizeable», «как редактировать веб страницу»… сотня вариаций разных запросов. Возможно в комментариях профи могут поделиться своими советами.

И да, раз уж речь зашла о советах, то мне бы еще хотелось получить от вас конструктивную критику и полезные советы. Возможно кто-то захочет размять мозги и сможет за пару часов накидать куда более функциональное решение. Или может кого-то этот пост натолкнет на интересные идеи, ведь таким способом можно принимать любой JSON запрос и сделать на его основе любую визуальную структуру. Было бы очень круто заиметь похожее универсальное решение, где можно любые данные распределять так как тебе это удобно, управляя простыми визуальными формами, drag and drop, resize и все такое прочее, чтобы красиво и функционально, а не вот это вот все. Хотя и так получилось неплохо, я считаю. Скорость агрегата, как и просил заказчик, теперь можно наблюдать из браузера и добавить что-то новое не составит большого труда.