Статус OPC-сервера на сегодня

[I_m]

Добрый день всем.

Подскажите, плз, статус OPC-сервера на текущий момент.
Можно им пользоваться?
Что с лицензированием? В смысле - какие условия использования?
Установил текущий (последний) СП4, попробовал - вроде работает. Но оно все без ключа.
Приборы ТСРВ-024М в кол-ве двух штук, пока. Я сомневаюсь, что заказчик что-то захочет приобретать.
Правда, их планов по кол-ву узлов не знаю.

Однако, если бы я раньше не имел дела с OPC UA, то даже бы и не понял - почему так выглядят Idem ID.
К слову, из трех имеющихся у меня клиентов только Prosys OPC отобразил их нормально.
Ладно, Simple OPC совсем старенький, но и Matrikon последней версии спасовал.

Поскольку меня в силу ряда причин OPC DA интересует, и в связи с вышесказанным вопрос: принцип формирования Item ID не изменится в дальнейшем? На более классический, так сказать.

[I_m]

И еще вопрос вдогонку: частота (период) опроса параметров в свойствах надора только для клиента ВСП4 значение имеет?
Или и для сторонних OPC-клиентов тоже?

[Дмитрий Пархоменко]

Здравствуйте!

Пользоваться конечно можно, как и OPC UA так и OPC Classic.
Лицензия у всех компонентов Взлет СП4 общая, мы решили не разбивать продукт на редакции, выполнив переход на подписку на обновления после 1 января 2020 года. Кстати, сейчас также стал доступным и новый Web-интерфейс для СП4.
Лицензия (ключ защиты) не нужна для работы с теплосчетчиками Взлет, а также Взлет ИВК-102(П). Таких приборов может быть неограниченное количество.

OPC UA - реальный OPC-сервер, OPC Classic является всего лишь прокси-сервером к нему для поддержки старых OPC-клиентов. Поэтому по наименованию тэгов мы исходили из требований OPC UA. Однако, по стандарту, мы указываем "человеческие" наименования (описания), как Вы уже успели заметить в разных SCADA, кто-то из них правильно отображает имена, а кто-то нет.
Внутренние же имена (уникальные, вроде SetEquipParam(X,Y)) мы менять не планировали. X и Y - идентификаторы внутри Вашей БД, они будут меняться только тогда, когда Вы будете действительно менять созданные ранее наборы.

Частота опроса в Наборах никак не влияет на частоту опроса в OPC, на это может влиять только сам OPC-клиент, и то как бы только для себя, т.к. наш OPC сервер старается выполнять чтение параметров без пауз.

[I_m]

Добрый день.

Спасибо за ответ. Роль и связь OPC UA и OPC Proxy мне понятна была с самого начала, немного только подход к выбору способа формирования имен тэгов удивил. Но так оно, наверное, даже и лучше, хоть и непривычно слегка. А то я уже чуть было не начал расстраиваться из-за длины имени тэга, как она мне представлялась поначалу. 

Что касается именно SCADA, то там все нормально - как адрес тэга задашь, так и будет.
А у OPC-клиентов клинит, как я понимаю, из-за наличия у тэга дочернего атрибута "ЕдиницаИзмерения".
Получается, что элемент является не конечным бенефициаром в ветке дерева. А может и нет. Может пытается построить адрес иходя из имени узлов дерева тэгов и сталкивается с чем-то непонятным, что не может адекватно интерпретировать. Во всяком случае, если в том же Matrikon Explorer не выбирать элемент, а просто скопировать нужный адрес, то читает как миленький, без вопросов. А вот сам сформировать не может. Даже не отображает имен тэгов, только до имени набора доходит, а дальше - пусто.

Что касается собственно опроса и пауз в нем - а в этом OPC-сервере нет возможность указывать период неактивности, как в варианте для ВСП3 было? Во всяком случае в служебных тэгах сервера я ничего похожего не увидел.

[Дмитрий Пархоменко]

А у OPC-клиентов клинит, как я понимаю, из-за наличия у тэга дочернего атрибута "ЕдиницаИзмерения".

Вполне возможно. Но это уже на совести создателей таких клиентов.

Что касается собственно опроса и пауз в нем - а в этом OPC-сервере нет возможность указывать период неактивности, как в варианте для ВСП3 было? Во всяком случае в служебных тэгах сервера я ничего похожего не увидел.

Подумаем над переносом этого функционала.

[Neskad]

Здравствуйте. Хочется узнать актуальную информацию по этим самым периодам неактивности.

На данный момент у нас работает связка ТСРВ-024М + АССВ030 + СП4 + OPCUA + SCADA.
Опрашиваются текущие параметры теплосчетчика. Обновление показаний происходит примерно раз в 20сек, что является избыточным и приводит к дополнительным расходам за услуги gprs.
Есть-ли какой-то способ увеличить период ожидания между циклическим опросом наборов?

[Дмитрий Пархоменко]

Здравствуйте. Хочется узнать актуальную информацию по этим самым периодам неактивности.

На данный момент у нас работает связка ТСРВ-024М + АССВ030 + СП4 + OPCUA + SCADA.
Опрашиваются текущие параметры теплосчетчика. Обновление показаний происходит примерно раз в 20сек, что является избыточным и приводит к дополнительным расходам за услуги gprs.
Есть-ли какой-то способ увеличить период ожидания между циклическим опросом наборов?

Здравствуйте!

Как я писал выше, частота опроса в Наборах никак не влияет на частоту опроса в OPC, опрос осуществляется по требованию OPC-клиента, то есть с какой периодичностью Ваша SCADA опрашивает параметры (тэги) с такой частотой мы и обращаемся к прибору. Периодичность следует менять на стороне SCADA.

Функционал из старого OPC сервера, по поводу принудительных пауз, мы пока не переносили в СП4 по причине не совсем правильного подхода, ибо сервер обязан выполнять чтение по требованию. Но если без этого никак, то есть SCADA такая что умеет только беспрерывно вести опрос, подумаем над этим вопросом.

[Дмитрий Пархоменко]

Мы добавили настройки периодчности опроса через OPC-сервер для каждого набора и сделали выбор стиля наименования тэгов: "идентификаторы" (как было, удобно и правильно для OPC UA) и "имена" (новое, удобное для OPC Classic) - см. рисунок.

Обновление Взлет СП уже доступно на форуме.