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

Версия для печати (настроить)

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

Подписаться

Автор Тема:   замаливаем грехи InTouch или DDE2OPC Bridge
Unregistered
Junior Member

Сообщений: 7
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 24 Ноября 2010 03:35ИнфоПравкаОтветитьIP

Всем привет. На предприятии используется InTouch 10 для сбора и отображения данных с цппс (РДУ). Система обособлена и работает удовлетворительно. Кроме InTouch, на объектах генерации предприятия используется самописанная MES полностью построенная на OPC. inTouch архивирует данные в своем формате, самописная скада на ms sql server. Данные с sql server-a, без проблем выводим на сайт компании (как мгновенные так и исторические). Сейчас возникла необходимость показать данные из InTouch на сайте компании и как следствие необходимость собирать данные от InTouch в самописную скаду. Покопавшись с тем что у нас стоит, пришли к выводу, что забирать данные можем только посредством DDE, а затем складывать в базу SQL. Чтобы не нарушать общую схему сбора данных самописной скады, решили что нужен DDE2OPC Bridge, который будет выполнять роль опс-сервера для inTouch и без проблем вписываться в нашу скаду. Поиск в интеренете естественно привел к такого рода ПО с соответствующей ценой. Решили написать свой "мост". Взяли пример OPC-сервера с opcconnect.com под дельфи и после небольшой доработки получили почти то, что нам и было нужно, но с одной проблемой - OPC-клиент локально видит этот OPC сервер. а на удаленной машине ругается, что класс не зарегистрирован. Думаю, есть какой-то косяк в функции регистрации сервера, какой именно - понять не хватает знаний.
Вопрос! Кто нибудь работал с примером от opcconnect и опробовал его на удаленной машине? Помогите с проблемой удаленного доступа к OPC-серверу и можем вместе сделать такой бридж бесплатным (цена в сети от 500$).
Можно поставить наш сервер локально относительно клиента, но "главный клиент" собирающий данные от других OPC-серверов крутиться на ws2008r2, а под ним DDE не живет.

PS. С помощью нашего OPC-сервера построенного на базе примера можно собирать данные с нескольких DDEserver-ов расположенных локально и в сети (NetDDE), умеет сохранять и загружать созданную конфу. Кто заинтересован в бесплатном мосту DDE-OPC, намылю исходник (D2009).

Unregistered
Junior Member

Сообщений: 9
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 25 Ноября 2010 07:47ИнфоПравкаОтветитьIP

Вопрос решен! На том же сайте есть еще один пример OPC-серва. Он адекватно регистрируется в системе и виден с удаленных машин.

xandrved
Junior Member

Сообщений: 11
Откуда: г.Кемерово
Регистрация: Сентябрь 2008

написано 07 Декабря 2010 11:03ИнфоПравкаОтветитьIP

У нас тоже работает самописная скада.Очень интересует, как у вас работает архивация мгновенных данных.
Если не секрет, с какой частотой регистрируются данные, в каком формате хранятся, какой размер архива...
Просто жутко интересно. А я могу о своей скаде рассказать.

Unregistered
Junior Member

Сообщений: 10
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 20 Декабря 2010 05:48ИнфоПравкаОтветитьIP

Привет! Дискретность архивации - по изменению данных. размер архива сейчас 130 Гб. Предполагаемый размер базы до архивации - 200 Гб (это около года). Данные собираются с OPC-серверов в SQLServer 2008 R2. Вся OPC-оснастка построена на компонентах dOPC от Kassl. В планах приобретение лицензии. Очень понравились. Не охвачен вопрос по HDA, но это на будущее в планах работ. Написаны: конфигуратор OPC-тэгов, многопточный архиватор OPC по заданной конфигурации. Программа для построения графиков по любым данным из базы с возможностью объединять масштабировать выделять тренды, создавать свои наборы тэгов. Неплохой инструмент для анализа нештатных ситуаций получился. (построен на базе TeeChart). К дельфям написаны простые компоненты для мониторинга и обработки сигналов (масштабирование, уставки, сигнализация, запись в журнал), эл. самописец + механизмы получения данных как напрямую с OPC-серверов так и с базы данных. Ну в общем довольны своей конструкцией, есть большой недостаток по графике. Не смогли найти ничего подходящего (цена/качество) для реализации красивых мнемосхем. На данный момент опрашиваются RealLab, СПТ, СПГ, СПЕ, БРКУ Нева, InTouch DDEServer, TraceMode 5.0. Подключение новых сигналов заключается в редактировании конфы и перезапуске архиватора. Необходимым и достаточным условием является наличие OPC-сервера для подключаемого устройства. ЭТО НЕ РЕКЛАМА! ))) МЫ НЕ ПРОДАЕМ!!!))) А чуть не забыл. вот еще у этих ребят взяли mobileeq.com. оповещаем по смс-кам сами себя чего у нас случилось.))) Ну теперь ваш рассказ. )

xandrved
Junior Member

Сообщений: 12
Откуда: г.Кемерово
Регистрация: Сентябрь 2008

написано 21 Декабря 2010 07:34ИнфоПравкаОтветитьIP

Привет! Мы используем контроллеры ADAM-5510(протокол PLCNET) и переходим на Premium (протокол MODBUS). Scada через собственные драйвера максимально быстро опрашивает контроллеры и посылает команды. Необходимости использовать ОРС нет.Архив построен на базе FIREBIRD (бесплатный).Архивация каждые 2 секунды, всего архивируется около 8 тысяч параметров. Архив с операторских станций сливается в одну базу (27 Гб за полгода).Почти 50 операторских станций с функцией управления и около 80 клиентских инсталяций с режимом наблюдения в реальном времени (обновление информации по сети каждые 2 секунды) и возможностью читать архивы. И оператор и клиент работают с одной и той же Scada.
Сейчас заканчиваем испытание новой системы архивация,которая использует файл собственного формата и не требует СУБД.Скорострельность новинки просто изумительная.Предполагается сделать ее открытой для всех.
Все ПО написано на С++ Builder 2006.

Unregistered
Junior Member

Сообщений: 11
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 22 Декабря 2010 07:41ИнфоПравкаОтветитьIP

А новая система архивация на какие объемы расчитана? И скорострельность это по запсиси или туда и обратно? Как на счет представлений, отчетов, сводных таблиц и все остальное что доступно по sql?

Добавление от 22 Декабря 2010 07:50:

Да вот еще хотел спросить. Какого типа данные храняться в Вашей базе (я имею ввиду непосредственно архивные значения параметров)? У нас все float (8 байт). Собираем чуть больше 2000 тэгов и база не в пример больше. Хотелось бы разобраться.

xandrved
Junior Member

Сообщений: 13
Откуда: г.Кемерово
Регистрация: Сентябрь 2008

написано 22 Декабря 2010 09:05ИнфоПравкаОтветитьIP

В каком виде хранить данные это вопрос принципиальный. Я тоже поначалу пытался для каждого тэга(или параметра) каждое новое значение писать в отдельную запись в таблице, но быстро от этого отказался. Считайте:8000 тэгов каждые 2 секунды это 8000*1800*24 записей в сутки. А еще индекс по таблице. Даже если использовать апертуру, то эффект только для дискретных или констант, для остальных не поможет. При таком подходе таблица очень быстро раздувается ... и количество переходит в качество,то бишь в тормоза.
Конечно неискушенный пользователь это проглотит, а "ленивый" программист порадуется, что можно на SQL легко создавать разные отчеты.
Мы используем другой подход. Для каждого тэга значения за один час собираются в блок, который упаковывется и сохраняется каждые 10 минут(дописывается или перезаписывается)в одну запись в таблице.
Таким образом записей становится в 1800 раз меньше и плюс упаковка (более эффективна чем запись по изменениям) в итоге архив меньше. Но считывать данные можно только часовыми блоками специальной программой. А как же отчеты? У нас архив это просто большой склад подробных данных для анализа технологических ситуаций. Для использования отчетов специальные программы периодически извлекают из этой кучи "важности",записывает их в базу данных ОРАКЛ в специально разработанные для отчетов таблицы и уже оттуда "ленивые" с помощью SQL создают отчеты и т.п.
Новая система архивации также построена по блочному принципу. Теоретически она расчитана на 4 млн.тэгов, но тестировалась реально на 20 тыс.Она специально оптимизирована по скорости записи и чтения.Выборка данных производится за небольшое фиксированое число шагов и не зависит от количества тэгов и объема архивов.

Unregistered
Junior Member

Сообщений: 12
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 23 Декабря 2010 07:37ИнфоПравкаОтветитьIP

Как все сложно у вас . Только не согласен, что при использовании аппертуры "эффект только для дискретных или констант", по моему как раз наоборот для часто меняющихся значений. а константы и дискреты... они ж по изменению, там аппертура вообще не нужна. И если вы каждые 10 минут проводите операции по упаковке и перезаписи блоков по каждому тэгу... тут потери данных нет? кстати, упаковка и перезапись - это джоб или свое приложение? Жаль нельзя посмотреть систему в действии, подход интересный но, честно, пока цитирую Станиславского :-). А систему пишите "под себя" или думаете выходить на рынок?

Добавление от 23 Декабря 2010 07:42:

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

xandrved
Junior Member

Сообщений: 14
Откуда: г.Кемерово
Регистрация: Сентябрь 2008

написано 23 Декабря 2010 12:43ИнфоПравкаОтветитьIP

SCADA заводская,а регистратор мой.Вместо апертуры я использую такой алгоритм:
Пусть X-значение,П-заданая допустимая погрешность( для дискретных и целых=1, для реалов обычно 0.3% шкалы или 0.001).
Вычисляем К=Х/П и округляем до целого.Накопленые с начала часа К хитро пакуем и пишем в архив единым блоком.Теряя в точности выигрываем в скорости и размере.
Статистика с реального объекта где проходит обкатка: 1169 самых разных тэгов, регистрация каждые 2 секунды(1800 точек в час),средний размер часового блока 216 байт.Такая статистика позволяет прогнозировать размер архива за любое количество часов.
Регистратор( в форме набора dll) бесплатный и ввиду нестандартности подхода вряд ли будет комерческим.
Материалы по регистратору есть на сайте xandrved.narod.ru,
но они сильно устарели,планирую после нового года их обновить.
Все приложения написаны на С++,"разговор" с регистратором по своему протоколу.

Unregistered
Junior Member

Сообщений: 13
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 24 Декабря 2010 09:54ИнфоПравкаОтветитьIP

Значит, у вас таки, значения пишутся раз в 2 секунды не зависимо от того изменились они или нет?

xandrved
Junior Member

Сообщений: 15
Откуда: г.Кемерово
Регистрация: Сентябрь 2008

написано 24 Декабря 2010 10:55ИнфоПравкаОтветитьIP

Именно так.Пишутся все значения, но тем не менее после упаковки они занимают меньше места.
При этом для каждого значения не нужно хранить временную метку(она вычисляется),а если значение повторяется, то вместо него записывается 1 бит.
Встречный вопрос: если значение пишется по изменению, то как вы определяете, чему было равно значение в момент Т?

Unregistered
Junior Member

Сообщений: 14
Откуда: Нерюнгри, Россия
Регистрация: Июль 2010

написано 26 Декабря 2010 14:40ИнфоПравкаОтветитьIP

В момент Т берется предыдущее значение параметра. подстановка вычисляется через простой sql-запрос организованный в виде хранимой процедуры. Нам не важно совпадение времЁн по разным параметрам внутри выборки. мы смотрим начало и конец выборки. есть определенные сложности с вычислениями между параметрами, но и они решаемы на стороне клиента. Кстати есть идеи по вычислению этого значения путем апроксимации с различной погрешностью (завсисит от используемой формулы), но это на будущее и пока нет необходимости.

[Это сообщение изменил Unregistered (изменение 26 Декабря 2010 15:16).]

Ваш ответ:

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


Ник:    Пароль       
Отключить смайлики

Все время MSK

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

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

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

Copyright © skunksworks.net, 2000-2018

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


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