- В этой теме 152 ответа, 10 участников, последнее обновление 5 лет, 11 месяцев назад сделано
.
-
Записи
-
Попробую обрисовать картину)))) В деревне стоят 2 ардуины ,со скадой они связываются по modbus.MQTT драйвер просто берт данные из определнных каналов и передает на брокер.Далее с брокера я эти данные принимаю на мобильных устройствах.
Коллеги, вот интересная статья по применимости MQTT в промышленном интернете вещей (IIoT). Понятно, что все уж очень красиво и безоблачно (точнее очень облачно, «Все в облака!» :))
Я полностью согласен с комментарием — стандарт нужен и нужны правила. Иначе бардак.Есть в статье одна бяка. А если прервется связь, а вы хотите выключить устройство ?
мало ли по какой вине, обрыв провода, проблемы у провайдера и так далее.
У вас в резервуаре стоит датчик с mqtt, где-то установлен насос и он заполняет этот резервуар и тут бац. нет связи, данные с датчика не поступают. Переполнение резервуара ? надо таки остановить насос и подождать восстановления связи ? а связи с насосом тоже нет 🙂Ну да, без разницы. mqtt позволяет легко и просто подключать кучу Scada, что плюс у этого протокола.
Судя по обратной связи, наш драйвер MQTT востребован. Особенностью MQTT является то, что не скада инициирует опрос, а контроллер, зная IP сервера (MQTT-брокера), публикует на нём данные. Скада затем забирает данные с брокера. Такой подход удобен, если сервер находится в интернете, т.к. он сам не может достучаться до контроллера в сеть предприятия. Ещё плюс, что с брокера данные могут читать различные клиенты. А так протокол как протокол ) Если не ошибаюсь, он работает только с текущими данными.
Я считаю проблемой этого «протокола» (поскольку его даже протоколом не назвали — транспорт) отсутствие какой либо определенной структуры данных. Т.е. по существу к каждому устройству придется писать свой обработчик — дешифратор структуры json. Почему то это считается плюсом — да, проще, да, (возможно) быстрее… Понятно, что никакой истории тут быть не может — это же аналог стеллажа с полочками — кто то положил — ты взял. По существу тут вся тяжесть работы перекладывается на клиента.
Да, в определенной области он нужен и удобен и хорош. Но говорить «выкидываем все, делаем только на MQTT» — впрочем как и в других областях — нельзя. ИМХО, но выстраданное годами…И еще — два-три поста назад — почему MQTT сравниваете со SCADA? SCADA — по существу отображалка/управлялка, а MQTT — транспорт к этой отображалке.
И по поводу многократного подключения — а кто мешает к ModBus подключить несколько SCADA? Вот например сейчас у меня переходной момент в переходе от 5.6 к 5.8 — так к одному шлюзу ModBus TCP подключено аж три Rapid SCADA. Да, если это управление то возможно только одно подключение на запись, иначе будет бардак. Но и MQTT не спасет при таком подключении — у него синхронизации вообще нет.Но и MQTT не спасет при таком подключении — у него синхронизации вообще нет.
Что-то должно быть, иначе какой в нем смысл? Тогда лучше OPC использовать.
Да и отсутствие архивов не делает его универсальным.
И вообще это утопия — сделать один протокол на все случаи жизни. В реальности это не работает, только в рекламных роликах и буклетах 🙂У него есть только сигнал клиенту, что данные топика изменились. А это уже дело клиента — обращать на это внимание или нет.
ОРС — тоже не панацея. DCOM однако…Я считаю, что каждой технологии лучше отвести свою нишу, наиболее ей подходящую. Т.е. не проблему подбирать под инструмент, а все-таки подбирать инструмент под проблему. Полностью согласен про показушные демонстрации.
a80808 ну попробуйте к Modbus RTU подключить несколько Scada, а мы посмотрим. Вот у RapidScada есть лайфхак и можно подключить две с разбежкой опроса в минуту, будет то одна опрашивать, то другая. Но это поддерживают далеко не все Scada системы.
- Для ответа в этой теме необходимо авторизоваться.