- В этой теме 32 ответа, 5 участников, последнее обновление 4 года, 3 месяца назад сделано
.
-
Сообщения
-
если к одному серверу будут подключены несколько коммуникаторов, а у них же могут быть и одинаковые каналы, не возникнет конфликт конфигураций?
Добавлю: данные будут получены Сервером то от одного Коммуникатора, то от другого. Для оператора данные будут «прыгать», и не сразу можно догадаться, в чём причина.
Подобный эффект очень редко может возникнуть даже на одном Коммуникаторе, если в процессе редактирования оказываются 2 разных КП с одинаковыми каналами. Но для этого требуется очень хитрая последовательность действий.
т.о., все кроется именно в агенте. догадывался, что править базу agent вручную надо, даже при изменении deployment profile на локальной машине. интересно, что даже администратор на месте не может внести изменения в станцию в плане профиля.
если это на месте заработает, то и удаленно тоже. профиль администраторов везде по умолчанию стоит, к самому агенту он подключается, но ничего не может сделать, прав нет на изменение профиля станции.
как правильно не изменить, а добавить регистрационные данные (в плане синтаксиса xml), т.е. создать несколько станций на у одного проекта с разными рег. данными?
агент как службу нет необходимости перезапускать?
(сейчас временно нет доступа к проектам, чуть позже отпишусь)
Пример файла C:\SCADA\ScadaAgent\Config\ScadaAgentConfig.xml
<?xml version="1.0" encoding="utf-8"?> <ScadaAgentConfig> <SecretKey>5ABF5A7FD01752A2F1DFD21370B96EA462B0AE5C66A64F8901C9E1E2A06E40F1</SecretKey> <Instances> <Instance name="MyInstance" directory="C:\SCADA\" /> </Instances> </ScadaAgentConfig>В Администраторе экземпляр должен также называться MyInstance.
Присылайте скриншоты проводника проекта из Администратора — проверим, а также логи Агента, если не удаётся подключиться.агент как службу нет необходимости перезапускать?
После редактирования ScadaAgentConfig.xml службу нужно перезапустить.
как правильно не изменить, а добавить регистрационные данные (в плане синтаксиса xml), т.е. создать несколько станций на у одного проекта с разными рег. данными?
Если Вы пришлёте диаграмму, на которой показана архитектура системы, то смогу дать более точные рекомендации. Сейчас вопрос понятен не до конца.
После редактирования вручную ScadaAgentConfig.xml и перезапуска службы агента удалось подключиться к удаленной станции и работать с ее проктом на локальной машине.
Что неудобно, так это то, что на локальной и удаленной машине станции, и, соответственно, проекты, должны иметь одинаковые ключи SecretKey, помимо самих имен станций. При переименовании станции, равно как и изменении ее ключа, придется править конфиг агента на месте, вручную. Т.е. такое (поэтому был вопрос про синтаксис, как его воспримет агент), не покатит:<?xml version=»1.0″ encoding=»utf-8″?>
<ScadaAgentConfig>
<SecretKey>5ABF5A7FD01752A2F1DFD21370B96EA462B0AE5C66A64F8901C9E1E2A06E40F1</SecretKey>
<Instances>
<Instance name=»LocalInstance» directory=»C:\SCADA\» />
</Instances>
<SecretKey>6BCD7FCDB479ACC123DEE859AEC365F329ABE778FA5B9FF616FAAB8290DEF1A5</SecretKey>
<Instances>
<Instance name=»RemoteInstance» directory=»C:\SCADA\» />
</Instances>
</ScadaAgentConfig>Коммуникатор удаленной станции подключить к локальной машине так и не получилось, при внесении в базу кп сервер локальной станции пишет норма, веб-интерфейс — сервер недоступен.
Может быть это как-то правильнее и удобнее по-другому сделать? Как подключить каналы удаленного коммуникатора в текуший проект на локальной машине.
Задача, в общем, была следующая:
Есть несколько удаленных машин, со своими проектами-экземплярами системы, они работают на месте. Есть еще одна машина, т.н. локальная, которая должна подключаться к вышеуказанным экземплярам систем и получать отдельные данные от каждой, т.е. быть сервером. Сервер не обязательно должен быть сопряжен с проектами удаленных машин, редактировать и работать с ними удаленно не требуется, хотя и приветствуется. Такое можно сделать, прибегнув в технологиям OPC (особенно UA) серверов, это получилось, и успешно было протестировано. Но задача состоит в том, чтобы OPC не использовать, также как и тунеллирование. Все машины находятся в одной локальной сети. Локальный сервер будет использоваться для сбора и отображения статистики работы по системам от удаленных машин.Тогда на удаленных машинах надо ставить RapidGate и одно из условий, они должны отличаться по номерам каналов. RapidGate валит все и вся. А доработка платная.
Имхо, в нынешнем состоянии когда все одинаковое или близко к одинаковому не очень удобный механизм…Что неудобно, так это то, что на локальной и удаленной машине станции, и, соответственно, проекты, должны иметь одинаковые ключи SecretKey, помимо самих имен станций.
Ключ на удалённой станции должен совпадать с ключом, указанным в соответствующем профиле развертывания в проекте. В этом и смысл.
Ключ, указанный для Агенте на рабочей станции, не играет никакой роли.Коммуникатор удаленной станции подключить к локальной машине так и не получилось, при внесении в базу кп сервер локальной станции пишет норма, веб-интерфейс — сервер недоступен.
Нужны скриншоты настроек.
Коммуникатор удаленной станции подключить к локальной машине так и не получилось, при внесении в базу кп сервер локальной станции пишет норма, веб-интерфейс — сервер недоступен.
Нужно сначала сделать принципиальный выбор:
1. На удалённых машинах ставить Rapid SCADA целиком и использовать Быстрый шлюз для связи между скадами. Это удобно, если нужна независимая работа объекта от главной скады.
2. На удалённых машинах ставить только Коммуникаторы. Это удобно для упрощения обслуживания.
Дальнейшая настройка будет зависеть от этого выбора.Если всё происходит в одной локальной сети, которая считается защищенной, можно сделать везде одинаковые секретные ключи.
RapidGate валит все и вся. А доработка платная.
Быстрый шлюз в процессе доработки, благодаря одному из наших заказчиков. Такова модель развития Rapid SCADA.
Итоги.
Коммуникатор подключить в нормальном режиме к локальной машине-серверу удалось только при соблюдении следующих условий, помимо согласования профилей Instance (имя станции и профиля, ключ, пароль и имя доступа к службе):
1. Номера каналов на разных удаленных станциях обязательно должны различаться, иначе на локальной машине из данных от коммуникаторов получится каша как в статусах, так и при дальнейшей реализации управления. При создании таких проектов лучше выбирать и резервировать диапазоны каналов для каждой удаленной станции заранее.
2. Коммуникатор, данные которого вы собираетесь получить с удаленной машины, должен их сам отправить на службу-сервер экземпляра системы целевой машины (!), т.о. в настройках Communicator-CommonParameters-Server нужно указать адрес целевой машины вместо Localhost.
И это крайне неудобно, т.к. чтобы не потерять полный функционал работы на удаленной машине, то придется создать там еще один дубляж того же коммуникатора уже для локальной службы сервера. А так как дополнительный коммуникатор не создается в текущей станции (Instance), то получим и двойную станцию в проекте, со своим профилем, нагрузка на линию связи с объектом получится двойная, если не поправить получение данных от одного коммуникатора в другой, но вкупе с этим и количество каналов текущей базы вырастет.
Аналогично база данных каналов, интерфейсы и проч.: при подключении нескольких удаленных станций она является общей в проекте, и тут главное не выгрузить лишнюю конфигурацию случайно, смотреть с чем вы работаете на данный момент.
Что удобно, так это то, что можно полностью работать с проектом удаленной машины на локальной, от загрузки конфигурации до просмотра статуса работы.Построение системы с настройками режима в коммуникаторах в TCP Server/Client/UDP для устройств для согласования не удалось, по крайней мере для КП типа OPC. Наверное, работает только для MODBUS и подобного.
Для всей такой архитектуры будет работать только один секретный ключ Instance на всех экземплярах Scada, т.к. для конфигурации агента невозможно создать отдельный секретный ключ для отдельной станции в проекте, а если все станции находятся в соединении в одном проекте на серверной машине, то на то и получается. Опция Ignore: Registration Keys не могу сказать для чего служит точно в полной мере.
После переименования Instance или ключа в проекте,- в базе агента их приходится править вручную, иначе далее проект будет невозможно и не выгрузить, и не загрузить. Часто при изменении данных в конфигурации базы проекта необходимо обновлять вручную представление отдельных элементов проекта, чтобы изменения имели силу и отобразились в представлении приложения Администратор.
В текущей версии разработки из-за невозможности работы службы-коммуникатора как сервера данных не могу порекомендовать создавать системы децентрализованного контроля/управления с локальными полными станциями только на чистой основе RapidSCADA. С применением UA-OPC, или с шлюзом RapidGate ситуация выглядит гораздо интереснее, система получится более легкая и гибкая при разработке и обслуживании.
- Вы должны авторизироваться для ответа в этой теме.