OPC-технология. Оптимизация обработки дан

Здравствуйте, господа специалисты!

Существуют ли какие-нибудь общие рекомендации по количеству тегов в группах при работе с OPC-сервером? Интересует в первую очередь быстродействие, как сервера так и клиента.

Попробую ещё раз .

Не интересует период опроса нижнего уровня. Вопрос относительно реализации верхнего уровня на OPC-технологии. Какой смысл изначально вкладывался разработчиками OPC-технологии в возможность объединить тэги по группам? И как определить оптимальное количество групп и тэгов в группах при разработке своего клиента?

С уважением.

Мы в основном работаем с PLKNet OPC сервером, но принцип должен работать и с любым ОРС.

На основании проб и ошибок получается такая картина:

В ОРС сервере при конфигурировании создаются группы тегов, которые должны быть распределены по контроллерам, т.е. одна группа тегов, один контроллер. Если в одной группе теги с разных контроллеров, то опрос нижнего уровня замедляется, тем сильнее чем больше разных "контроллеров" в группе.

Когда клиент ОРС присоединяется к серверу, то он создает свою отдельную группу тегов в памяти ОРС сервера в которую тот передает данные из свох групп. Genesis32 создает группы для каждого окна, сервера аварий и архивации. В итоге одни и теже данные считываются из разных групп и скорость падает. На практическом опыте установлено, если не принимать специальных мер, если больше 500 тегов в проекте, то вы получите улитку, а не визуализацию тех. процесса.

К тому же установлено, что Genesis32 не уничтожает созданые группы при закрытии окна Gwx32. Они остаются в ОРС сервере. Попробуйте открывать и закрывать всплывающее окно с данными в режиме исполнения. В итоге ОРС сервер до того будет перегружен неиспользуемыми группами тегов, что передача замедлится неимоверно. Единственный выход перезагрузить ОРС сервер.

Вот как раз самое интересное: а какие специальные меры могут приниматься? Или эти меры справедливы только в рамках конкретной Genesis32?

Дело в том, что OPC-сервер передает клиенту информацию только по тем тэгам группы, которые изменились.  И, насколько мы разобрались, далеко не факт, что элементы одного списка (списка изменившихся тэгов) располагаются в том же порядке, что и элементы другого списка (всей группы).

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

Вот мы и думаем: может, есть какие-то другие способы решения? Или в OPC-технологии какое-то стандатное решение предполагается?

С уважением,

Обмен данными между клиентом и сервером может осуществляться в двух режимах - синхронном и асинхронном [http://www.cta.ru/pdf/1999-3/software1_1999_3.pdf]. При асинхронном варианте обмена сервер сам оповещает клиента об изменившихся значениях данных, на которые подписался клиент (по возможности с частотой, заданной клиентом при создании группы)...

Мы используем асинхронный вариант обмена, при разработке своего собственного клиента, подключающегося к Simatic WinCC v. 5.0. Собственно и OPC-технология приглянулась только потому, что можно разгрузить слабенького клиента от процедуры периодических запросов и анализа пришедшей информации.