OPC-UA мост в MQTT


#1

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

Итак у нас тут активно движется 1С:Вещей - то есть потребность работать в терминах бизнес-логики (писать на 1С) с устройствами… То есть типа следующего

Процедура ПриПолученииДанныхСУстройств(ИмяУстройства, ИмяСобытия, Данные)
    РезультатАнализаДанныхУстройств = СделатьСтранноеСДанными(Данными);
    Если РезультатАнализаДанныхУстройств.НужноЧтоТоДелать Тогда
         ЗапуститьКакойНибудьБизнесПроцесс(РезультатАнализаДанныхУстройств);
    КонецЕсли;
КонецПоцедуры

Соответственно нам нужно события телеметрии с устройств получать в 1С системах - то есть необходимо спроектировать систему которая будет выполнять следующее

  • подписывать 1С на события с устройств
  • получать данные с устройств

Но тут возникает 2 проблемы

  • во первых - все боятся принимать управляющие сигналы обратно: из 1С в устройство.
  • во вторых - все производители устройств “старого режима” очень не любят реализовывать открытые протоколы, а делают проприетарные.

Первая проблема пока никак не решается в общем виде - есть только наметки на рабочее место сотрудника, который валидирует управляющие сигналы прямо на рабочем месте и нажимает кнопку “Применить”. То есть человеческий фактор остается.

Вторая проблема как раз намечена к решению - исполнением прокси-контролеров.

В порядке проработки проблематики - первое виденье схемы. Суть в том что:

  • для бизнес-систем выставляем единый протокол MQTT (ну и AMQP конечно трансформация)
  • телеметрию собираем с полевого уровня
  • управляющие сигналу отправляем на уровень SCADA чтобы дальше работал валидатор управляющих сигналов уже на уровне АСУТП.

Чего пока неясно и еще в проработке

  • у меня в тестовом контролере уже есть Modbus клиент - https://wirenboard.com/wiki/index.php/Modbus-client, фактически у меня уже есть полевой уровень.
  • мосты OPC-2-MQTT пока в виде службы (сервиса) не нашел
  • уровень SCADA систем не имеет в первом ближении единой открытой спецификации, а уже про MQTT вообще ничего не знает. Надо искать дальше

Кстати не только я один работаю в этом направлении:

“Балеринщики” также смотрят на сервисы которые могут AMQT-MQTT, соответственно скоро под влиянием рынка все больше контролеров “цехового уровня” должны будут переходить на MQTT протокол: таковы реалии.


HighLoad мёртв - читая программу конференции
#2

Мне бы хотелось конечно вообще отказаться от OPC серверов - но это слишком глобально для получателей систем. Поэтому пока такие мысли. Продолжение следует.


#3

https://opcconnect.opcfoundation.org/2017/10/should-i-use-opc-ua-mqtt-amqp/


#4

Это я читал, концепция за которую топит человек понятно. Вопрос сейчас лежит в плоскости реализации - кто уже реализовал OPC-2-MQTT на промышленном уровне.


#5

А для тех случаев, когда аппаратной реализации нет, вроде вот эту платформу давно пилят:



#6

Я их юзал - собственно в эту сторону я и смотрю. Но так как клиент русскоязычный придется смотреть сюда https://github.com/thingsboard/thingsboard-gateway а уже потом что-то свое творить.

Потому как самые важные фишки у них платные https://thingsboard.io/products/thingsboard-pe/

Другое дело что у них программный gateway.


#7

https://devicehive.com
Вот эта ничего. Она опенсурсная и много чего под нее уже сделано.