Коллеги! Предлагаю поделится своим мнением (соображениями) о SCADA/HMI в облаке - ОВЕН CLOUD, КОНТАР SCADA, другой вариант. Ну, и в частности как на видео


Подключение к DispSky

Скудный набор поддерживаемых устройств валит все на корню.

Шлюзы стандартные iRZ или с вашими прошивками ?
Шлюзы других производителей где ?

Это больше к производителям приборов)!

УТОПИЯ (ОВНО)
И на кого это рассчитано?
Можно на коленке выдумывать свои контроллеры и ПО, только срок жизни данного оборудования короткий, если учесть потрясения в экономике то тем более.

Шире на мир смотрите, шире!

А отечественному производителю, лично я, не дам и цента!

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

Похожая система
Подключение удаленных объектов к enertec.cloud
Еще одна от российских представителей Данфосс
тут презенташка в ПДФ

Так что Ваш продукт не уникален

Облако это хорошо, но есть НО.

1. шлюзы должны поддерживаться все возможные из упаковки. Тот же Teleofis например с m2m или openVPN или IPSec, ну там l2tp и так далее. То есть на ваших серверах должны быть возможности все это запустить и настроить - это касается GSM шлюзов.
Это кроме стандартных Ethernet - RS485 (RS232) преобразователей, где можно таки иметь выделенные IP.
2. Иметь возможность подключать свои dll для работы со сторонними протоколами - Меркурий и Энергомера это мизер.
3. Полноценная работа с Modbus RTU, TCP например если используется так же GSM роутер с симками без статики


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

Речи об уникальности не было. Ветка про Ваше мнение - как Вы к этому относитесь.

Должно быть платным? Готовы сами применять или уже используете....

Таких систем не 2 и не 3, их гораздо больше .
Возможно мнением поделитесь по системе и политике DispSky

Я вижу, что в DispSky есть СПИСОК поддерживаемых популярных устройств. Их недостаточно?
По Вашему предложению - это касается организации канала. А что вверху?
Мне кажется, такие решения для хорошо подготовленных инженеров с глубокими навыками программирования/администрирования.
Что передается, в Вашем случае, внутри TCP - modbus?

Не достаточно. У нас в стране масса приборов, которые бы люди хотели видеть в Scada. Логика, Пульсар, всякие расходомеры газа, корректоры газа и т.д. У вас банальщина из пары счетчиков ???

Чтобы можно было подключать свои dll, со стороны Scada должна быть поддержка, какой-то модуль, который примет данные и будет отправлять данные ну и для программеров правила написания своих библиотек для протоколов.
Как это сделать, вам решать, на каких языках тоже. Соответственно документация как это делать тоже. Это называется развитием продукта и в ваших же интересах.

Поверх ТСР можно работать и с COM портами. То есть если на другом конце GSM - RS485 или Ethernet-RS485 например.

Полагаю, это вопрос производителей устройств - если они предусмотрели подключение к диспетчеризации - молодцы. Оценивайте их. COM по верх TCP, очень кривое решение.

А зачем импортные хаить? Что там китайцы про Вас говорят Вам интересно? Думаю нет.
Я же задал вопрос для кого Ваш продукт? В ответ тишина.
Я отвечу - Ваш продукт для освоения бюджетных денег, для этого много ума не надо.
Свой человек заказал, свой человек оплатил, свой человек принял, свой и бабки в обратку получил. Ключевое слово СВОЙ.
Точно такое же умный дом от ростелекома. Да еще в сколково аналоги.
Монополист предлагает товар берите что есть.
Только брать или не брать решать клиенту.
А наши клиенты требовательны, особенно когда есть альтернатива.

А для расширения кругозора советую съездить в Китай или Корею и там вы поймете, что ваше НОУ ХАУ есть ХАУНО.

такое же кривое, как и использование собственных протоколов вместо стандартных.

И если что, COM никогда не умрет, так как Ethernet не выдерживает таких расстояний, исключая оптику конечно, но это куда большие деньги, если использовать COM.

Соглашусь, собственный протокол это плохо.
Для телеметрии хорош MQTT.

myscada у вас и MQTT насколько помню собственный с шифрованием....

з.ы. если эта облачная Scada ваша, предусмотрите возможность пилить дрова на устройства для разработчиков. Какой-то API для взаимодействия. dll будете сами подключать после проверки. Возможность коммерции, а то писать дрова на халяву не очень интересно.

Возможность тестировать, так как сложно без устройств и дебага отловить ошибки.
Когда реализуете что-то, свистите... просто есть под другую систему дровишки для чтения различных устройств (язык C#). в будущем я бы поучаствовал. Так как Облачная Sсada с такими возможностями была бы актуальна.

з.ы. а не кастрированное овноклауд...

MQTT действительно зашифрован. Но делали это на основе стандартных решений Mosquitto. Сейчас для интеграции ПЛК СЕРЕБРУМ (в системы телеметрии), есть OPC UA и REST API.

В ролике - DispSky, SCADA партнеров. Своя SCADA скоро.