Стартовая страница › Форумы › Понять, как работает ПО › Быстрый Шлюз (инициатор соединения)
- В этой теме 19 ответов, 3 участника, последнее обновление 2 года, 2 месяца назад сделано Mikhail.
-
АвторСообщения
-
23.09.2021 в 15:32 #20883vgУчастник
Здравствуйте!
Собственно вопрос: кто является инициатором соединения при обмене данными главного сервера, на котором объединяется информация всех удалённых экземпляров Scada, с этими самыми экземплярами? Экземпляры стучатся на главный сервер или главный сервер опрашивает на предмет наличия новых данных?
- Эта тема была изменена 2 года, 6 месяцев назад от vg.
23.09.2021 в 15:41 #20885manjey73УчастникЭкземпляры стучаться на главный сервер, Сервер обрабатывает данные.
Шлюз должен быть только на удаленной машине, на Сервере он не обязателен.24.09.2021 в 18:12 #20893vgУчастникВ документации и на сайте не нашёл информации о том, на каких ОС работает модуль «Быстрый шлюз».
И в целом, верно ли, что где работает Rapid SCADA, то там работают все его модули и драйверы по умолчанию?
24.09.2021 в 19:57 #20895manjey73Участник@yg на Linux не работает только модуль Уведомлений из-за каких-то проблем в Mono.
Все остальное работает нормально.На счет шлюза я создавал тему, но идентифицировать проблему пока не удается.
Предлагал Михаилу сделать пересылку на его сервер.У меня практически все каналы из шлюза со статусом архивный, хотя вроде передача архивов выключена. Время синхронизировано. При чем независимо от принимающего сервера, Windows или Linux
24.09.2021 в 22:58 #20896vgУчастникСпасибо.
Из-за особенностей сети заказчика хотим протестировать вариант с промежуточным сервером (скорее всего на Linux), который будет получать данные с устройств (традиционно, когда Scada является мастером) и скопом по быстрому шлюзу отправлять все данные на главный сервер. Краем глаза посмотрел. По-моему там просто настраивается соответствие каналов между экземплярами Scada.
25.09.2021 в 09:11 #20897manjey73УчастникДа, сейчас настройки гуд, не то, что в первой версии, только все и только в те же каналы 🙂
27.09.2021 в 18:14 #20898MikhailМодераторДобрый день!
Из-за особенностей сети заказчика хотим протестировать вариант с промежуточным сервером (скорее всего на Linux), который будет получать данные с устройств (традиционно, когда Scada является мастером) и скопом по быстрому шлюзу отправлять все данные на главный сервер.
Да, хорошая схема.
Рекомендую всё настраивать в рамках единого проекта (в Администраторе).
Вопрос: сможет ли Администратор достучаться до Агентов на удалённых серверах?28.09.2021 в 06:30 #20900vgУчастникВозможно не совсем понял про единый проект. Планирую считывать промежуточным сервером данные со всех измерительных устройств в сети (это будет экземпляр Rapid Scada без интерфейса). Затем шлюзом переправлять эти данные в проект на главном сервере, который объединяет под своей «крышей» проекты разных филиалов заказчика и уже в нём реализовывать всю необходимую обработку и логику. Мы об одном и том же? 🙂 Из контекста, как я понял, можно настроить экземпляры Rapid Scada без Администратора, но я так не умею 🙂
Если я правильно понимаю, то главному серверу в рассматриваемой конфигурации и не надо никуда стучаться, так как у него нет никаких линий связи (они подразумеваются только на промежуточном сервере), а инициатором соединения является удалённый промежуточный сервер.
Работоспособность конфигурации планируем тестировать в ближайшее время в сети заказчика с помощью простого проекта.28.09.2021 в 06:45 #20901vgУчастникИ ещё подскажите по типу каналов, которые принимают данные по шлюзу. Я попробовал и Дорасчётный ТИ, и Телеизмерение. Работает и то и то. Есть какая то идеологическая разница кроме использования формул и частоты отработки?
- Этот ответ был изменен 2 года, 6 месяцев назад от vg.
28.09.2021 в 13:28 #20909MikhailМодераторДа, об одном и том же. В Администраторе можно настроить «профили развёртывания» для каждого удалённого сервера, чтобы скидывать на них конфигурацию со своей рабочей станции. Но для этого нужно иметь доступ к удалённым серверам по IP. Такой подход позволяет избежать двойной работы по созданию входных каналов.
И ещё подскажите по типу каналов, которые принимают данные по шлюзу.
Желательно не передавать дорасчётные каналы, чтобы сократить трафик. Они могут вычисляться на главном сервере. Если столкнётесь, что такого режима недостаточно, напишите.
28.09.2021 в 15:42 #20912vgУчастникНо для этого нужно иметь доступ к удалённым серверам по IP. Такой подход позволяет избежать двойной работы по созданию входных каналов.
Звучит удобно, но этого доступа к сожалению не будет. Из-за особенностей сети заказчика инициатором подключения должны быть удалённые сервера.
29.09.2021 в 09:45 #20913manjey73Участник@vg — l2tp + IPSec вам в помощь 🙂
Если на Linux то пакет xl2tp и strongswan (ipsec)
назначаете статические IP в сети VPN и рулите всеми промежуточными серверами как хотите независимо от сетей заказчика.
Надеюсь администраторы заказчика организуют прохождение пакетов для внутреннего VPN созданного для Scada ?Тогда вы можете использовать Администратор и рулить настройками и изменениями хоть из дома, вы так же должны будете подключаться как VPN клиент.
29.09.2021 в 16:59 #20914MikhailМодераторИз-за особенностей сети заказчика инициатором подключения должны быть удалённые сервера.
Типичная ситуация. В данный момент выход — VPN. В будущем постараемся предложить какое-то встроенное в Rapid SCADA решение.
29.09.2021 в 21:04 #20915manjey73УчастникМихаил, так по сути виртуальная сеть и нужна. Только с редким опросом, в случае подключения Администратором опрос на интенсивный режим. Перестали обращаться, через паузу опять в редкий режим.
19.01.2022 в 19:44 #21473vgУчастникЗдравствуйте!
Подскажите пожалуйста за что отвечает параметр «Период времени, мс», равный 10000 по умолчанию в «Параметры передачи текущих данных» во вкладке «Конфигурация» модуля «Быстрый шлюз»?
Значения текущих данных передаются сразу при получении (Триггер «При получении») или накапливаются в течение упомянутых выше 10000 мс?
-
АвторСообщения
- Вы должны авторизироваться для ответа в этой теме.