Альтернатива OPC-UA

Question

Есть ли достойная альтернатива OPC-UA в качестве решения для доступа к данным процесса системы, состоящей из различных ПЛК? Что-то независимое от платформы и может «говорить» с продуктами разных брендов?

Я слышал о MQTT, но, похоже, это скорее транспортный протокол, и только это. У него нет всех предметов более высокого уровня, таких как информационное моделирование и т. Д.

Спасибо за вашу помощь!

Answer 1

OPC - единственный стандартный способ связи с ПЛК. OPC DA - старая альтернатива. OPC UA является новым и рекомендуется, в настоящее время. До OPC были только проприетарные протоколы и общие протоколы, такие как Modbus, но они являются только транспортными протоколами более низкого уровня, как вы уже упоминали.

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

Обратите внимание, что некоторые ПЛК также могут разговаривать с OPC UA, что делает его стандартным.

И OPC UA действительно стандартизован как IEC 62541, гарантируя его независимость.

Обновление 17/07/19: OPC UA теперь определяется также как Industry 4.0 Communication, как я писал в своей недавней статье.

Кроме того, в будущей версии 1.04 (в настоящее время в RC) OPC UA будут определены альтернативы Pub/Sub (с использованием UDP & AMQP first MQTT позже), а также будет определена альтернатива протокола WebSocket/JSON, которая облегчит использование в веб-приложениях.

Answer 2

MQTT становится все популярнее как протокол выбора для I.o.T. У этого есть свои короткие предложения - однако его простота часто рассматривается как сила, тогда как OPCUA несет накладные расходы на проектирование комитетом.

Если вам нужно объединить два, вы можете, как рассмотреть пытаемся наш простой шлюз mqtt2opcua

Answer 3

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

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

Вот почему мы создали альтернативный протокол под названием Вупса в моем университете. Мы решили основать его на HTTP + JSON. Мы попытались сделать протокол, похожий на OPC-UA: он имеет информационное моделирование, публикацию/подписку и даже многопроцессорные запросы. Все это полностью с открытым исходным кодом.

Мы только что выпустили версию 1.0 здесь: http://www.woopsa.org/

Вы можете получить исходный код непосредственно на нашем GitHub: https://github.com/woopsa-protocol/Woopsa

В принципе, наш протокол только стандартизированный RESTful API с использованием HTTP + JSON.Например, вы можете прочитать значение, сделав GET /woopsa/read/Temperature и он ответит вам в формате JSON:

{"Value":24.2,"Type":"Real"} 

Вы также можете получить дерево объектов с помощью meta слова, например: GET /woopsa/meta/, который даст вам что-то вроде что:

{ 
    "Name":"WeatherStation", 
    "Properties": [ 
    {"Name":"Temperature","Type":"Real"}, 
    ... 
    ], 
    "Methods": { ... } 
    "Items": [ 
    "Thermostat", 
    ... 
    ] 
} 

Answer 4

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

MQTT - это уровень передачи сообщений, который не обеспечивает функциональную совместимость по дизайну. Он не определяет формат полезной нагрузки, не указывает, как один передает определенный тип данных, временную метку, значение, иерархию или что-то еще, что позволит приложению понимать передаваемые данные. Вы можете создать действительный сервер MQTT, который испускает XML, JSON или пользовательские форматированные данные, которые являются текстовыми, зашифрованными, закодированными в base-64 или что-либо еще, что вам нравится. Единственный способ, которым клиентское приложение может взаимодействовать с вашим сервером, - это заранее знать, какой формат данных сервер будет производить и принимать.

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

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

Суть в том, что OPC-UA предназначен для взаимодействия, а MQTT - для простой пользовательской связи. MQTT должен расти, прежде чем он станет альтернативой OPC-UA.

Answer 5

Unserver - это продукт, предназначенный для решения точной проблемы, описанной в этом вопросе.

Он способен разговаривать с различными полевыми устройствами и предоставлять унифицированный HTTP API на . Он интегрируется с устройствами через Modbus RTU, но в будущем будут добавляться другие распространенные протоколы.

Короче говоря, сначала сконфигурировать данные «тег», как это:

{ 
    "name": "tank1", 
    "device": "plc1", 
    "properties": [ 
    { 
     "name": "level", 
     "address": "HR0", 
     "type": "numeric", 
     "raw": "int16" 
    } 
    ] 
} 

Тогда вы можете работать с тегом используя API конечных точек создается автоматически:

GET http://localhost:9000/tags/tank1 

{ 
    data:{ 
    level: 1 
    } 
} 

Отъезд documentation для получения дополнительной информации. Продукт является бесплатным для оценки и некоммерческого использования.

Отказ от ответственности: Я часть команды. Надеюсь, это полезно.