OpenSCADA как посредник посередине
Author |
Message |
Written on: 06. 02. 2018 [18:12]
|
mobelus86
Paul Schmidt
Topic creator
registered since: 05.02.2018
Posts: 8
|
Здравствуйте. Удалось разобраться как работать с OpenSCADA в серверном режиме и в клиентском режиме.
Но что делать, если хочется использовать openSCADA "Посередине" между Клиентом и Сервером, причём:
Клиент на 1-ой машине (свой ip_1) <=> 2-ая машина "посередине" с openSCADA (свой ip_2) <=> Сервер находящийся на 3-ей машине. (свой ip_3)
Как в таком случае настроить в OpenScada входящий/исходящий Транспорты, или кто на что должен ссылаться ? Протокол везде Modbus.
|
Written on: 06. 02. 2018 [18:49]
|
ponysonata
Anastasia Anastasia
registered since: 04.02.2018
Posts: 1
|
я бы сделала - мастером для ip1 и слейвом для ip3
ip1 - слейв
ip3 - мастер соотв.
|
Written on: 06. 02. 2018 [20:15]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"mobelus86" wrote:
Здравствуйте. Удалось разобраться как работать с OpenSCADA в серверном режиме и в клиентском режиме.
Но что делать, если хочется использовать openSCADA "Посередине" между Клиентом и Сервером,
Раз не хотите изучать демонстрацию, которая одновременно и сервер и клиент ModBus, а также не читаете документацию о модуле, где описан режим шлюза, чтобы данные не переваливать, то ничего не делайте!
P.S. Какое отношение этот и предыдущий вопрос имеет к документации, кроме того, что Вы её не читаете!?
Learn, learn and learn better than work, work and work.
|
Written on: 08. 02. 2018 [21:29]
|
mobelus86
Paul Schmidt
Topic creator
registered since: 05.02.2018
Posts: 8
|
Здравствуйте. На сколько смог ознакомился с демонстрационным видео и документацией и несколько продвинулся со своей исходной задачей. Отдельно извиняюсь за пост не в том разделе.
Итак, если принять в рамках задачи уже упомянутые пользователем ponysonata термины:
Slave - Сервер
Master - Клиент
"ponysonata" wrote:
я бы сделала - мастером для ip1 и слейвом для ip3
ip1 - слейв
ip3 - мастер соотв.
ponysonata Не до конца понимаю, как можно организовать всё так как вы описываете.
Как я на пока что понял мне необходимо построить следующую взаимосвязь:
3я машина (ip_3) – Сервер – Эмулятор Modbus Server (Slave) – условный ВХ.транспорт
|
v
Шлюз-Клиент – Client (Master) – Настройка шлюза на ??? транспорт
^
2ая машина “посередине” (свой ip_2) – Шлюз – OpenSCADA Gate (Client and Server)
v
Шлюз-Сервер – Server (Slave) – Настройка шлюза на ??? транспорт
|
v
1ая машина (ip_1) – Клиент – OpenSCADA Client (Master) – ВЫХ.транспорт
Задача именно такова – Получить данные от Сервера на 3-ей машине, через OpenSCADA-шлюз, стоящую на 2-ой машине перенаправить данные в конечном итоге на последнюю 1-ую машину, и чтобы они были успешно прочитаны в OpenSCADA-клиенте.
Пока получилось настроить следующие 2 части:
1) Подключение OpenSCADA-клиента к Серверу через настройку на OpenSCADA-е ВЫХодного транспорта, тэгов и т.д.
3я машина (ip_3) – Сервер – Эмулятор Modbus Server (Slave) – условный ВХ.транспорт
и
1я машина (ip_1) – Клиент – OpenSCADA Client (Master) – ВЫХ.транспорт
2) Установка соединения между OpenSCADA-сервером и OpenSCADA-клиентом с настройкой на Серверной стороне ВХодного транспорта и на Клиентской стороне ВЫХодного транспорта
2ая машина (ip_2) – Сервер – OpenSCADA Server (Slave) – ВХ.транспорт
и
1ая машина (ip_1) – Клиент – OpenSCADA Client (Master) – ВЫХ.транспорт
Эта часть казалось мне важной для выстраивания взаимодействия между 2-ой и 1-ой машинами, чтобы в будущем быстро настроить тем самым вот эту часть уже Шлюзового взаимодействия:
2ая машина “посередине” (свой ip_2) – Шлюз – OpenSCADA Gate (Client and Server)
v
Шлюз-Сервер – Server (Slave) – Настройка шлюза на ВХ.трансорт транспорт
|
v
1ая машина (ip_1) – Клиент – OpenSCADA Client (Master) – ВЫХ.транспорт
ПРОБЛЕМА: После того как я посмотрел на то, какие возможности настройки есть у режима Шлюза, у меня остались вопросы и недопонимания следующего толка:
ВЫХодной транспорт – Клиент Master – нужно настроить для того, чтобы ПРИНИМАТЬ данные с сервера, ибо именно в ВЫХодном транспорте мы указываем IP-шник места, где находится сервер.
А через Сбор данных -> Модуль -> Modbus -> +Наш_источник_данных. Внутри «Нашего_источника_данных» мы уже указываем именно этот самый ВЫХодной транспорт
ВХодной транспорт – Сервер Slave – мы настраиваем по IP-шнику, с которого клиент потом будет считывать данные, которые сервер будет ОТДАВАТЬ клиенту, согласно тем тегам, которыми мы наполним наш сервер. (Теги для которого мы определим в Транспортные протоколы -> ModBus -> Тест (Режим: Данные; ВХ.транспорт:Тот, который мы добавили))
ШЛЮЗ, который мы можем настроить в Транспортные Протоколы -> ModBUS -> gate
Умеет ПЕРЕНАВПРАВЛЯТЬ ВХодной транспорт на -> какой-то ВЫХодной транспорт.
То есть я надеялся получить, в результате движение данных по следующей схеме:
Сервер ip_3 (ВХ) –> Шлюз-Клиент (ВЫХ) -> ip_2 <- Шлюз-Сервер (ВХ) -> Клиент ip_1 (ВЫХ)
А в итоге получается, что, движение данных можно настроить только как-то так:
Сервер ip_3 (ВХ) ??? Шлюз-Сервер (ВХ) -> ip_2 -> Шлюз-Клиент (ВЫХ) ??? Клиент ip_1 (ВЫХ)
Подскажите, что именно я понимаю неверно, или где произвожу настройку некорректно?
|
Written on: 09. 02. 2018 [15:02]
|
mobelus86
Paul Schmidt
Topic creator
registered since: 05.02.2018
Posts: 8
|
Подскажите всего одну деталь.
Согласно описанию конфигурации узлов ModBus:
http://oscada.org/wiki/Modules/ModBus/ru#.D0.A0.D0.B5.D0.B6.D0.B8.D0.BC_.D1.83.D0.B7.D0.BB.D0.B0_.D0.BF.D1.80.D0.BE.D1.82.D0.BE.D0.BA.D0.BE.D0.BB.D0.B0_.22.D0.94.D0.B0.D0.BD.D0.BD.D1.8B.D0.B5.22
Настройка протокола Modbus в режиме ШЛЮЗА - позволяет только настроить перенаправление Входного транспорта (1) в какой-то Выходной транспорт (2) в рамках одной машины, на которой стоит openSCADA. То есть фактически позволяет нам перенаправить данные только с сервера (slave) на клиент (master). Но что делать, если хочется пробросить данные от клиента (которые он получает с сервера) на другой сервер, который будет распространять не свои данные а именно те, которые ему будет ретранслировать клиентская сторона ? Возможно ли такое ?
Ибо если мы можем организовать только движение данных исключительно от сервера к клиенту
Server to Client (или Input transport -> Output transport)
А в обратную сторону никак. То как же осуществлять переброс данных, если нельзя организовать переброс данных через например:
Server to Server
или
Client to Server
|
Written on: 09. 02. 2018 [15:54]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"mobelus86" wrote:
Настройка протокола Modbus в режиме ШЛЮЗА - позволяет только настроить перенаправление Входного транспорта (1) в какой-то Выходной транспорт (2) в рамках одной машины, на которой стоит openSCADA. То есть фактически позволяет нам перенаправить данные только с сервера (slave) на клиент (master). Но что делать, если хочется пробросить данные от клиента (которые он получает с сервера) на другой сервер, который будет распространять не свои данные а именно те, которые ему будет ретранслировать клиентская сторона ? Возможно ли такое ?
Это не шлюз тогда вовсе, а пересылка между серверами, третьим узлом, что во первый и основное не понятно зачем и во вторых прозрачно, абстрогировавшись от структуры PDU сделать нельзя (что делает шлюз).
А значить нужно на том клиенте, что пересылает сконфигурировать оба сервера с данными, пусть даже чтение их блоками-строкой, а затем отдельной процедурой копировать значение этих данных блоков из атрибутов одного сервера на другой.
Но ещё раз! Какой в этом смысл, если Сервер2 может сам взять всё нужное с Сервер1, поскольку они в одной сети.
"mobelus86" wrote:
А в обратную сторону никак. То как же осуществлять переброс данных, если нельзя организовать переброс данных через например:
Server to Server
или
Client to Server
Можно всё, понимать только нужно происходящее!
Learn, learn and learn better than work, work and work.
|
Written on: 12. 02. 2018 [10:13]
|
mobelus86
Paul Schmidt
Topic creator
registered since: 05.02.2018
Posts: 8
|
"roman" wrote:
не понятно зачем Какой в этом смысл, если Сервер2 может сам взять всё нужное с Сервер1, поскольку они в одной сети.
Понимаю, что выглядит странно и бессмысленно. По условию задачи необходимо организовать трёхзвенную схему передачи данных, где:
Сервер1 (Железный / Hardware) -> Сервер2 (программный / Software = OpenSCADA) -> Клиент (программный / Software = OpenSCADA)
Сервер1, который железный уже присутствует, остальные части, то есть Сервер2 и Клиент хочется как раз использовать OpenSCADA. Таковы просто условия исходной задачи.
"roman" wrote:
а затем отдельной процедурой копировать значение этих данных блоков из атрибутов одного сервера на другой.
Подскажите:
1) "отдельной процедурой" имеется ввиду через OpenSCADA или имеется ввиду процедура какой-то сторонней программы ?
2) "из атрибутов одного сервера на другой" подскажите как это можно сделать или в какой части документации есть информация, по данному вопросу ?
|
Written on: 12. 02. 2018 [11:06]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"mobelus86" wrote:
"roman" wrote:
не понятно зачем Какой в этом смысл, если Сервер2 может сам взять всё нужное с Сервер1, поскольку они в одной сети.
Понимаю, что выглядит странно и бессмысленно. По условию задачи необходимо организовать трёхзвенную схему передачи данных, где:
Сервер1 (Железный / Hardware) -> Сервер2 (программный / Software = OpenSCADA) -> Клиент (программный / Software = OpenSCADA)
Сервер1, который железный уже присутствует, остальные части, то есть Сервер2 и Клиент хочется как раз использовать OpenSCADA. Таковы просто условия исходной задачи.
Не понимаете, почему и рисуете структуру шлюза, а говорите про пересылку!
Т.е. из того что Вы говорите там:
Клиент (программный / Software = OpenSCADA)
.............<= Сервер1 (Железный / Hardware);
.............<= Сервер2 (программный / Software = OpenSCADA)
Сервер2 (программный / Software = OpenSCADA)
.............<= Сервер1 (Железный / Hardware);
Что реализуется стандартно и тут нет месту шлюзу, если Сервер2 кроме данных из Сервер1 ещё имеет собственные данные и функции, иначе он тут вообще лишний!
"mobelus86" wrote:
1) "отдельной процедурой" имеется ввиду через OpenSCADA или имеется ввиду процедура какой-то сторонней программы ?
2) "из атрибутов одного сервера на другой" подскажите как это можно сделать или в какой части документации есть информация, по данному вопросу ?
Естественно, процедурой OpenSCADA, а копировать используя API пользователя и в логическом контроллере LogicLev или JavaLikeCalc.
Хотя это явно лишнее, исходя из описанного выше!
Learn, learn and learn better than work, work and work.
|
Written on: 14. 02. 2018 [11:16]
|
mobelus86
Paul Schmidt
Topic creator
registered since: 05.02.2018
Posts: 8
|
Да ретрансляция важна.
Ведь openSCADA, которая стоит на 2-ой машине должна одновременно и получить данные с железного сервера, который стоит на 1-ой машине и передавать эти полученные данные на 3-тью машину, где стоит ещё одна openSCADA, которая должна быть последним конечным клиентом, принимающим информацию.
Роман, вы верно указали причину, почему выбрана такая схема работы (передачи данных до клиента):
"roman" wrote: если Сервер2 кроме данных из Сервер1 ещё имеет собственные данные и функции,
ибо c 1-ой машины приходят свои данные, а на 2-ой хочется получить данные с 1-ой, на 2-ой машине провести с ними некоторые манипуляции и передать результат на 3-тью машину
Исходя из того, что я нашёл тут:
http://wiki.oscada.org/Doc/OpisanieProgrammy/part3
Мне необходимо реализовать вариант «3.2. Дублированное серверное подключение.»
Возможно мне так же подойдёт вариант с «3.8. Устойчивая, распределённая конфигурация.»
1) Вопрос мой тут только в том, как это сделать чисто технически ? По пункту 3.8 пока изучаю описание, которое присутствует по ссылке.
По поводу
"roman" wrote:
используя API пользователя и в логическом контроллере LogicLev или JavaLikeCalc.
Внутри данного раздела:
http://wiki.oscada.org/Doc/ModBus#h592-7
Нашёл часть про 2.1. API функции исходящих запросов
2) Если я верно понимаю, то можно использовать messIO() для пересылки данных между моими двумя серверами, о которых я говорил в сообщениях выше ?
Осуществлять это возможно, через настройку Transport Protocols -> User Protocol и используя возможности JavaLikeCalc.
Остаётся один вопрос - Как переслать данные из пользовательского протокола в ModBus
3) Есть ли возможность данные из БД одной openSCADA, которая запущенна на первой машине забрать и поместить в БД на второй openSCADA, которая запущенна на второй машине ?
Пока разбирался с остальным заметил, что к openSCADA по мимо прочего можно подключиться через Web. В итоге настроил всё как мне надо с использованием браузера, а именно вот так:
1-ая машина с железным сервером
2-ая машина с openSCADA, на которой
2.1 настроен ВЫХоднрой транспорт на железный сервер соответственно. На 2-ой машине я настроил свою мнемосхему, которая получает данные с 1-ой машины.
2.2 так же настроен ВХодной транспорт для WEB подключения через HTTP протокол на отдельный ip-шник с портом (*).
3-тья машина в которой в браузере указал вышеупомянутый ip-шник с портом (*) и получил в браузере нужную мне работающую мнемосхему
Именно такое взаимодействие и хочется организовать как раз. Только получать данные и работающую мнемосхему отображать на 3-ей машине не в браузере, а в ещё одной openSCADA.
Вот в таком описании надеюсь теперь максимально точно будет понятно, что я хочу получить в итоге
4) Подскажите как настроить именно такое взаимодействие ?
|
Written on: 14. 02. 2018 [13:58]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"mobelus86" wrote:
Да ретрансляция важна.
Не нужна!
"mobelus86" wrote:
ибо c 1-ой машины приходят свои данные, а на 2-ой хочется получить данные с 1-ой, на 2-ой машине провести с ними некоторые манипуляции и передать результат на 3-тью машину
Что и требовалось доказать — второй сервер лишний, поскольку "провести с ними некоторые манипуляции" может сам клиент.
А если нужно реальное резервирование то это делается на одном уровне с конечным клиентом, т.е. нужно Server2 поднять до уровня клиентов и назвать Client2. Настройка резервирования в документации детально описана!
Learn, learn and learn better than work, work and work.
|
|
|