Есть ли достойная альтернатива OPC-UA в качестве решения для доступа к данным процесса системы, состоящей из различных ПЛК? Что-то, что не зависит от платформы и может «разговаривать» с продуктами разных брендов?
Я слышал о MQTT, но, похоже, он больше похож на транспортный протокол, и только. В нем нет всего более высокого уровня, такого как информационное моделирование и т. Д.
Спасибо за вашу помощь!
OPC - единственный стандартный способ связи с ПЛК. OPC DA - старая альтернатива. OPC UA является новым и рекомендуется в настоящее время. До OPC были только проприетарные протоколы и общие протоколы, такие как Modbus, но, как вы упомянули, это просто транспортные протоколы более низкого уровня.
OPC UA довольно уникален, особенно с информационным моделированием. Благодаря этой функции он открывает новые возможности связи для систем и приложений более высокого уровня в дополнение к простой связи с ПЛК.
Обратите внимание, что некоторые ПЛК также могут использовать OPC UA по умолчанию, что делает его стандартом в этом отношении.
И OPC UA действительно стандартизирован как IEC 62541, что гарантирует его независимость.
Обновление 17/07/19: OPC UA теперь определяется также как Индустрия 4.0 Общение, как я писал в своей недавней статье.
Обновление 20/05/05: OPC UA версии 1.04 определяет альтернативы Pub / Sub, использующие UDP для безопасной многоадресной передачи данных в локальных сетях и AMQP / MQTT для безопасной доставки данных и событий через брокера в облачные системы. Версия 1.04 также определяет альтернативу протоколу WebSocket / JSON, которая упрощает использование в веб-приложениях. Пока что ни один из них не является широко доступным, но мы надеемся, что он станет популярным в период 2020-2021 годов.
OPC-UA имеет несколько очень интересных частей, особенно касающихся информационного моделирования, взаимодействия и шаблона публикации / подписки.
Однако, несмотря на то, что это стандарт в самом строгом смысле слова, я обнаружил, что для использования его в веб-приложении вам необходимо запрограммировать сервер шлюза. Потому что он использует сырые сокеты и двоичный (хотя и быстрый) протокол сериализации.
Вот почему мы создали в моем университете альтернативный протокол под названием 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",
...
]
}
В практическом промышленном применении 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.
MQTT становится все более популярным протоколом для I.o.T. У него есть свои недостатки - однако его простота часто рассматривается как сильная сторона, в то время как OPCUA несет накладные расходы на проектирование комитетом.
Если вам нужно объединить два, вы можете попробовать наш простой шлюз mqtt2opcua.
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
}
}
Дополнительную информацию см. В документации. Продукт бесплатен для ознакомления и некоммерческого использования.
Отказ от ответственности: я часть команды. Надеюсь, это будет полезно.
Я только что представил другой подход к этой проблеме. Проект называется ELTRA IoT.
Это облачная служба как посредник, а компоненты конечного пользователя, которые действуют как представление устройства или интерфейс оператора (https://www.eltra.ch/)
В первую очередь он был создан для упрощения интеграции устройств CANopen с приложениями для смартфонов, но я быстро понял, что его можно использовать для любого проекта IoT.
Этот проект вдохновлен архитектурой CANopen и FDT.
Первая идея заключалась в том, чтобы предоставить решение, которое позволяет вывести ваше устройство в Интернет с использованием веб-стандартов, таких как REST / JSON (избегайте двоичных протоколов, шлюзов, брандмауэра, проблем с прокси и всего этого персонала, который усложняет весь этот процесс) в короткие сроки. .
Веб-стандарты, такие как HTTP / REST / JSON / WebSocket, хорошо работают со всеми операционными системами и архитектурами, а также позволяют легко интегрировать приложения для конечных пользователей на любом современном языке.
Основные особенности:
SDK доступен на Github с открытым исходным кодом:
https://github.com/eltra-ch/eltra-sdk
На данный момент библиотека реализована в .NET Standard и протестирована с Windows, Linux (x64 и ARM32), Android, IPhone.
Пакет Nuget доступен по ссылке:
https://www.nuget.org/packages/Eltra.Connector/
Если сложность OPC UA является излишней, а Woopsa не подходит для вашего дизайна, тогда ELTRA может быть альтернативой.
отказ от ответственности: этот проект является частью моей магистерской диссертации, а сервис eltra.ch является моим частным веб-сайтом.
