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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Вот почему мы создали альтернативный протокол Woopsa в моем университете. Мы решили основать его на 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",
    ...
  ]
}

Ответ 3

В практическом промышленном применении 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.

Ответ 4

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

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

Ответ 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
  }
}

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

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