Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Получение данных с OPC сервера - разъясните некоторые моменты (страница 1)

Версия для печати (настроить)
Страницы: 1 2

Новая тема | Написать ответ

Подписаться

Автор Тема:   Получение данных с OPC сервера - разъясните некоторые моменты
SNike
Junior Member

Сообщений: 1
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 22 Января 2007 11:57ИнфоПравкаОтветитьIP

Данные с сервера OPC можно получать либо путем "подписки" на их изменение, либо непосредственно путем их чтения. Используется OPCDA 2.0, т.е. данные буду возвращаться в любом случае через DataCallback. Неясен один момент.

Суть такова: необходимо получать данные каждые, скажем, 15 секунд. Используем "подписку" на их изменение. Если данные меняются часто, то все нормально, т.е. к примеру, за 30 секунд получим данные 2 раза, на 15-ой секунде и на 30-ой. Однако, если данные реально изменятся один раз за 30 секунд, то мы получим их только один раз, на 30 секунде, а данные за 15-ю секунду не получим.
Как можно получать данные независимо от их изменения, вот в чем вопрос. Или же придется самому в программе добавлять таймер, и на него навешивать операцию чтения? Может быть есть более простой путь чем использование собственного таймера?

scserg
Junior Member

Сообщений: 2
Откуда: Кишинев,Молдова
Регистрация: Июль 2006

написано 22 Января 2007 15:25ИнфоПравкаОтветитьIP

Что за сервер ?

Добавление от 22 Января 2007 16:10:

И с чем связана привязка ииенно к этому времени? Или Вы опасаетесь получить недостоверные данные ?
Если так, то можете не опасаться . По опыту работы с OPC серверами (около 5 лет) с такой ситуацией не
сталкивался (если сервер не левый). Кроме того многие сервера позволяют получить время последнего
обновления и статус тэга ("Good" или "Bad"), а также информацию о том запущен ли сам OPC сервер и
когда, сколько тегов сконфигурировано и т.д. и т.п. А если еще запускать сервер как NT servis (если доступно ), то при случайном закрытии он запустится снова .
Чего именно Вы хотите добиться?

SNike
Junior Member

Сообщений: 3
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 22 Января 2007 16:45ИнфоПравкаОтветитьIP

Да нет, дело не в достоверности данных. Сейчас занимаюсь системой сбора данных. Хотелось бы чтобы в базу заносились данные каждые N секунд, или минут, в общем неважно. Главное чтоб они непременно поступали в нужные моменты времени без пропусков.
Таким образом получим непрерывный поток информации, по которому можно строить графики и производить расчеты.
Хотя, может быть есть другие подходы? Или может быть для этих целей не стоит пользоваться подпиской на данные...

scserg
Junior Member

Сообщений: 3
Откуда: Кишинев,Молдова
Регистрация: Июль 2006

написано 22 Января 2007 17:27ИнфоПравкаОтветитьIP

В принципе если запросите OPC , то он отдаст значение переменной при последнем изменении . Тут нет проблем.
Но допустим , что по какимто причинам переменная стала изменять своё значение чаще - картина получится
смазанная . Однако уж если кровь из носа нужно 15 секунд ,попробуйте сервер с устанавливаемым временем обновления сервера и устанавливаемым временем обновления клиента . Эти сервера относятся к коммуникационным OPC серверам (дополнительный OPC сервер ,позволяющий пересылать данные как между
локальными так и между удаленными OPC серверами ). Там действительно возможно обновлять данные через
10 ms , а клиента через 20 секунд . Но стоит ли овчинка выделки ?
Я использую LinkMaster от KEPware ,но есть и другие .

SNike
Junior Member

Сообщений: 4
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 22 Января 2007 17:38ИнфоПравкаОтветитьIP

Как раз нет, немного не так. Если данные обновляются часто (например каждые 50 ms), а подписка выставлена на те самые 15 секунд, то все равно изменение данных будем получать не каждые 50 ms, а каждые 15 секунд. Для этого и предназначено UpdateRate у группы.

Меня же наоборот терзает другая проблема - что делать если нужно получать данные чаще чем они меняются?

scserg
Junior Member

Сообщений: 4
Откуда: Кишинев,Молдова
Регистрация: Июль 2006

написано 22 Января 2007 17:52ИнфоПравкаОтветитьIP

получать данные чаще чем они меняются?
Если данные не меняются , значит старые данные достоверны, зачем грузить PC , сеть и прочее бесполезной работой ? Это свого рода оптимизация .

SNike
Junior Member

Сообщений: 5
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 23 Января 2007 08:44ИнфоПравкаОтветитьIP

Это конечно логично. Но, однако, в базе данных будут пробелы. Скажем, строим график считывая из базы данных значения. Например, начали перекрывать задвижку, соответственно расход стал уменьшаться. Все это уменьшение фиксируется в базе. Но вот расход стал равен нулю, и в течение 30 минут так все и оставалось. Тогда если строить график будет неясно что происходило в это время (в эти 30 минут), т.к. данных нет вообще. Остается только предполагать что расход в данное время имеет то же значение что и в момент последнего изменения. Но, а вдруг в это время просто, скажем, вышел из строя компьютер и данных нет не потому что они не меняются, а потому что техническая неисправность.

scserg
Junior Member

Сообщений: 5
Откуда: Кишинев,Молдова
Регистрация: Июль 2006

написано 23 Января 2007 10:28ИнфоПравкаОтветитьIP

Именно так и будет .График отслеживаемой величины в эти 30 минут покажет нулевое значение .
Для получения более полной информации о причине необходим мониторинг исполнительных механизмов .
Ничто не мещает организавать отдельный тренд для этого .
Если сдохнет комп-р или будет выключен, то тут надо рассматривать организацию и структуру сети .
Всегда или почти всегда возможно провести диагностику информационной системы . Например :
- источником является контроллер или удаленный сервер .Тогда выберем сигнал или пепеменную ,
которая не остаётся постоянной ,а всегда изменяется в нормальных условиях .Для контроллера имеющего внутренние чясы или удаленного сервера - это могут быть секунды . Если нет изменения - проблема (а если ещё использовать в комбинации с этим и статус тэга,то диагностика почти безошибочная). Это стандартный приём , но это всё больше относится к авариям и неисправностям .
Я бы не стал всё это смешивать .Мониторинг параметров отдельно ,мониторинг аварий отдельно . При
необходимости их несложно сопоставить и определить причину отклонения или неисправности.
Если короче ,то хочу сказать, что в нормальных условиях не стоит опасаться -OPC сервер одно из
самых простых и надежных решений . Для нештатных ситуаций необходимо продумать методы и принципы
диагностики . А вот тут и есть возможность проявить себя.

SNike
Junior Member

Сообщений: 6
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 23 Января 2007 10:49ИнфоПравкаОтветитьIP

Да, я как раз об этом и задумывался.

С одной стороны, если обеспечить непрерывный поток данных вне зависимости от их зменения, то само отсутствие данных будет признаком аварии. Но одновременно это будет дополнительно нагружать и комп.

С другой стороны, если реагировать только на изменение данных, то придется усложнять реализацию для анализа тревог.

На самом деле все что мне нужно - это складывать данные в локальную базу. Только вот как определить где пробел в потоке из-за неисправности, а где из-за отсутствия изменений данных, вот это вопросик. Может быть есть какие-то стандартные подходы, позволяющие не слишком сильно усложнять код?

scserg
Junior Member

Сообщений: 6
Откуда: Кишинев,Молдова
Регистрация: Июль 2006

написано 23 Января 2007 11:24ИнфоПравкаОтветитьIP

В нормальных условиях при отсутствии изменения данных пробела не должно
быть ,т к OPC сервер передаст значение переменной.
А вот при неисправности разрывы в графиках будут .И тут ничего не сделать . OPC сервер использевать или что-то другое - это не имеет
значения . Решения лежат в другой плоскости, не имеющей отношения к
OPC стандарту .Так что ломать голову и пытаться решить задачу за счет OPC сервера бесполезно .
Эту проблему помогают решить резервируемые системы .Однако - это совершенно другая задача .
Если нужно просто создавать или работать с базами данных - действуйте .
Мне кажется Вы пытаетесь решить решить задачи баз данных ,диагностики,
аварийного мониторинга причем одновременно .
Это сложно, и хотя Козьма Прутков (Нельзя обьять необятное) против -
дерзайте. Чем чёрт не шутит когда бог спит .

@su tp
unregistered
написано 23 Января 2007 11:35  ПравкаОтветитьIP

SNike
в базе данных будут пробелы
Тогда если строить график будет неясно что происходило в это время (в эти 30 минут), т.к. данных нет вообще
В SCADA Genesis32 имеется штатное средство для архиватора: в случае, когда данных нет при условии нормального функционирования OPC-сервера - писать в архив предыдущее значение. Таким образом, архив получается непрерывным и канал сбора данных не перегружается.

R0MER
Member

Сообщений: 89
Откуда: Russia
Регистрация: Июль 2003

написано 23 Января 2007 11:38ИнфоПравкаОтветитьIP

В SCADA Genesis32 имеется штатное средство для архиватора: в случае, когда данных нет при условии нормального функционирования OPC-сервера - писать в архив предыдущее значение. Таким образом, архив получается непрерывным и канал сбора данных не перегружается.

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

@su tp
unregistered
написано 23 Января 2007 11:46  ПравкаОтветитьIP

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

Но может быть ситуация, что данные не меняются из-за стабильности технологического процесса, в этом случае, если они достоверны, то и их статус будет соответствующий.

SNike
Junior Member

Сообщений: 7
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 23 Января 2007 12:09ИнфоПравкаОтветитьIP

Да, дело действительно упирается в стабильность процесса.
Вот на примере той же задвижки.
Задвижка закрыта, расход = 0. Последнее что передаст OPC - значение 0 в момент полного закрытия задвижки. Пусть, например, это произошло в 17.00.
Далее задвижку начали открывать в 18.00. Тогда сервер среагирует на изменение расхода (скажем, расход стал = 1) и передаст новую порцию данных, которую и запишем в базу (т.е. эту 1)

Получается картина что в базе есть такие записи:
17.00 - 0
18.00 - 1

Период с 17.01 по 17.59 выпадает. Как в этом случае можно выйти из положения чтобы диагностировать причину отсутствия данных в этот период.

Как вариант я думаю в базу записывать соответствующие флаги при старте программы сбора, при её останове, при ServerShutDown, или при ItemQuality = Bad
Может у кого есть более универсальное решение?

Павел Мощицкий
Member

Сообщений: 1791
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 23 Января 2007 19:49ИнфоПравкаОтветитьIP

SNike
Может у кого есть более универсальное решение?
Может я не догоняю, но кто мешает задать OPC-серверу другую частоту опроса тегов?
Тогда сервер среагирует на изменение расхода
В первую очередь среагирует прибор УСО и сервер тут, как промежуточная инстанция. Такое впечатление, что на OPC пытаются свалить не продуманность проектирование конкретной реализации АСУ ТП.

SNike
Junior Member

Сообщений: 8
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 24 Января 2007 09:16ИнфоПравкаОтветитьIP

Частота опроса тут не поможет. При использовании в клиенте подписки на изменение данных (использование интерфейса IOPCDataCallback) какую бы частоту опроса не выставляли, все равно данные получим при непосредственном изменении того же расхода. Изменится расход - среагирует прибор - OPC передаст клиенту данные. Если же расход постоянен, скажем = 0, и так в течение часа, то при UpdateRate = 15 минут, сервер каждые 15 минут проверяет изменился ли расход. Но расход не меняется целый час, и данные клиент получит только через час, то есть когда OPC проверит изменения в четвертый раз. Или я где-то ошибаюсь?

Добавление от 24 Января 2007 09:21:

Кстати, и еще попутный, по теме топика, вопрос, т.к. сейчас нет раельной возможности это опробовать.
Пусть в OPC-группе 4 тэга. Данные получаем все тем же путем - подписка на их изменение.
Как сервер вернет данные если изменения только в одном тэге, а в остальных 3 изменений нет.
Он через IOPCDataCallback вернет все четыре тэга или же только тот, который изменился?

Добавление от 24 Января 2007 10:02:

Вопрос о том какие тэги возвращает сервер OPC снят: он возвращает только те, которые действительно изменились. Для описанного примера возвратится только один тэг вместо четырех.

SNike
Junior Member

Сообщений: 9
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 02 Февраля 2007 10:28ИнфоПравкаОтветитьIP

И еще вопрос в тему, может кто сталкивался.
При написании клиента OPC добился-таки получения данных каждые 30 секунд независимо от того было ли реальное их изменение или нет.
Сделал так:
1. Соединился с сервером OPC
2. Создал группу (UpdateRate = 30 сек.)
3. Добавил в группу нужные элементы
4. Создал обработчик для OnDataChange
5. Подписал группы на этот обработчик
6. При помощи IOPCAsincIO2.SetState установил группу в неактивное состояние
7. Каждые 30 секунд (по таймеру) вызываю IOPCAsincIO2.Refresh и в обработчике получаю данные

Насколько верно такое решение, или может тут есть какие-то подводные камни?

XShura
unregistered
написано 05 Февраля 2007 09:43  ПравкаОтветитьIP

Судя по документашке, в этом случае сервак должен вернуть код ошибки E_Fail, и событие OnDataChange не произойдет.

Добавление от 05 Февраля 2007 09:51:

Дополню предыдущее сообщение...
Вам надо вызывать метод IOPCAsyncIO2::Read, в этом случае активность группы или тэгов не имеет значения.

SNike
Junior Member

Сообщений: 10
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 05 Февраля 2007 10:00ИнфоПравкаОтветитьIP

Но, как ни странно, OnDataChange все же происходит, и качество тэгов Good

XShura
unregistered
написано 05 Февраля 2007 10:03  ПравкаОтветитьIP

Значит сервак не соответствует Compliance Test

SNike
Junior Member

Сообщений: 11
Откуда: Великий Новгород
Регистрация: Январь 2007

написано 05 Февраля 2007 10:13ИнфоПравкаОтветитьIP

Нет, все же он соответствует. Сейчас вот все же раскопал OPC DA 2.0 спецификацию.
Вот выдержка:

SUBSCRIPTION via IOPCDataCallback
Enable Callbacks: FALSE
Group Active State: Active
Item Active State: Active

Server Behavior:
The Value and Quality are the values that the server obtains from the device at a periodic rate sufficient to accommodate the specified UpdateRate. If the Quality has changed from the Quality last sent to the client, then the new value and new quality will be sent to the client through the IOPCDataCallback::OnDataChange method, and the cache of the server should be updated with the acquired value and quality. If the Quality has NOT changed from the Quality last sent to the client, the server should compare the acquired value for a change that exceeds the Deadband criteria. If the change in value exceeds the deadband criteria, , then the new value and new quality will be sent to the client through the IOPCDataCallback::OnDataChange method, and the cache of the server should be updated with the acquired value and quality.


AsyncIO2::SetState - разрешить или нет DataCallBack.

IOPCAsyncIO2::Refresh (При активных группе и элементах):
The Values and Quality for all the Active items in the group are sent to the client through the IAdviseSink::OnDataChange method. The Value and Quality are the values that the server has in cache.

Возможно я ошибаюсь, но наверное такой вариант получения данных правильный, или же все-же что-то не так?

MuadDib_guest
unregistered
написано 05 Февраля 2007 10:28  ПравкаОтветитьIP

Небольшое уточнение по стандартному архиватору Genesis32 (TrendWorx). Не знаю точно, что идет в архив при Bad Quality тега, но при просмотре архива через штатное средство TrendWorx ActiveX Viewer на участках Bad тренд не прорисовывается, а при установке туда визира оператор видит ???? вместо значения.

А вообще TrendWorx Data logger, судя по всему, пишет данные только по изменению значения тега.

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика