www.InTouch.su

Добрый день.
Кто-нибудь имел дело с данными с меткой времени в InTouch'e?
Имеем OPC сервер KEPServerEx, собирающий информацию с ПЛК SCADAPack по протоколу DNP 3.0.
Данный протокол поддерживает данные с меткой времени и буферизацию неотправленных сообщений (в ПЛК).
После обрыва связи с ПЛК и последующем восстановлении, получаем данные с метками времени, соответствующими времени во время обрыва связи. Легко проверяется тем же LinkMaster'ом, например. InTouch получает данные с KEPSerever'а по протоколу SuiteLink, в котором также заявлена поодержка меток времени. На практике же все данные из буфера недоставленных сообщений интерпретируются как данные реального времени, что и отражено на исторических трендах. В чем причина такого поведения InTouch'а?
Заранее спасибо.

InTouch не оперирует историческими данными, только RealTime. DotField-ы .Time... показывают время опроса переменной с сервера в/в и время это присваивается в InTouch-е. Поэтому Ваши "старые" значения становятся "текущими".
Т.е. бесполезно подставлять в InTouch буферизированные данные.

Если InTouch не поддерживает метку времени источника, то почему вообще SuiteLink позиционируется как протокол с временными метками.

The Suitelink Protocol is based on TCP/IP and runs as a service on Windows
NT 4.0. It is best used for industrial applications where Value Time Quality,
extensive diagnostics, and high throughput are important.

Зачем он [SuiteLink] нужен, если InTouch отметает метку и берет только значение.
или дело в том, что локальный InTouch (я имею ввиду не WSP) не меняет своей структуры с момента зарождения с конца 80-х. тогда об этом не думали и не закладывали подобные решения?

Mikhalych писал(а):Если InTouch не поддерживает метку времени источника, то почему вообще SuiteLink позиционируется как протокол с временными метками. Зачем он [SuiteLink] нужен, если InTouch отметает метку и берет только значение.

У WW есть не только InTouch. Метка времени неплохо обрабатывается Historian, IAS.
Да и дело не в метке времени как таковой...
ПО WW не работает с буферизированной информацией (OPC HDA), только с реалтайм (OPC DA, DA-сервера). Вся накопленная в контроллерах информация при передаче в ПО WW воспринимается как реалтайм (если вообще воспринимается). Для буферизации разработаны собственные средства Store&Forward.
Для защиты обрыва связи верхнего уровня систем (ПО) с нижним (контроллеры) рекомендуется (разработчиком ПО) использовать резервированные каналы (например Profibus/Ethernet + MPI) и резервирование серверов в/в на уровне ПО.

Т.е. если строить систему телемеханизации скважин на Wonderware, то для обеспечения буфферизации надо ставить по месту (в шкафу телемеханики, рядом с ПЛК грубо-говоря) некоторый ПК с единственной возлагаемой на него функцией Store&Forward (либо сразу ставить PC-совмеcтимый контроллер)?
?

Либо нормально реализовать каналы связи

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

При том, что есть предложения от других производителей в эту сторну. и не одно.

Mikhalych писал(а):А также куча АВР, резервируемые компы, две-три сети передачи данных, и трезвые электрики, которые любят без спроса выключать питание, а также дрессированные мыши, которые не будут перегрызать кабеля антенны в шкафу ТМ.

Вряд ли всё выше перечесленное является проблемой разработчика ПО (WW) Можно, конечно, закладывать в возможности ПО и такие аспекты, но ... тогда Вы неприятно удивитесь цене на продукт.

Mikhalych писал(а):подобный функционал считают у WW не продуманным, что резко затрудняет применение ПО WW в системах телемеханики. вот в этом направлении стоило бы им действительно двигаться, а не красивые символы рисовать.

Каждому - своё. Увы Хотя по поводу "красивых символов" я с Вами согласен, но у слишком многих от их "красивости" снесло башню. Что касается систем телемеханики, то внедрения в РФ есть, значит люди нашли решения.

Mikhalych писал(а):При том, что есть предложения от других производителей в эту сторну. и не одно.

Некоторым проще (Siemens, A-B). Свои контроллеры, свой софт, заточенный в первую очередь под них. А WW выпускает только ПО. Далеко не все контроллеры (даже одного вендора) поддерживают буферизацию данных (и структура буфера может разниться). Поэтому довольно трудно сваять SCAD-у, которая бы подстраивалась под конкретный тип контроллера.

Загляните:
http://opchda.info/index.php?menu=files&id=14
Может, пригодится? Хотя, как по таким данным построить InTouch-тренд?

Генератор зла писал(а):

Mikhalych писал(а):А также куча АВР, резервируемые компы, две-три сети передачи данных, и трезвые электрики, которые любят без спроса выключать питание, а также дрессированные мыши, которые не будут перегрызать кабеля антенны в шкафу ТМ.

Вряд ли всё выше перечесленное является проблемой разработчика ПО (WW) Можно, конечно, закладывать в возможности ПО и такие аспекты, но ... тогда Вы неприятно удивитесь цене на продукт.

Не нужно придумывать. Просто SCADA должна обеспечивать работу по существующим современным протоколам телемеханики, например, DNP3.0. А проблемы со связью в системах телемеханики - это более распространенная ситуация, чем цеховое/площадное производство.

Генератор зла писал(а):

Mikhalych писал(а):Что касается систем телемеханики, то внедрения в РФ есть, значит люди нашли решения.

Можете назвать пример и может быть описание данной системы? Я слышал, что используют, но более детально информацию не так просто найти.

Генератор зла писал(а):Некоторым проще (Siemens, A-B). Свои контроллеры, свой софт, заточенный в первую очередь под них. А WW выпускает только ПО. Далеко не все контроллеры (даже одного вендора) поддерживают буферизацию данных (и структура буфера может разниться). Поэтому довольно трудно сваять SCAD-у, которая бы подстраивалась под конкретный тип контроллера.

Опять таки есть ПЛК, поддерживающий протокол с буферизацией DNP3.0 (не распространено, но есть, тот же SCADAPack). Нужно чтобы SCADA тоже это поддерживала DNP3.0 (например, ClearSCADA). Я согласен с тем, что буфферизация она во многом завязана на оборудования одного производителя. Но не считаю это неразрешимой проблемой, например, для WW. Просто проще предложить Store&Forward.

В конце-концов есть Телескоп и его контроллеры ТК - отечественная разработка, где буфферизация выполняется по своему закрытому протоколу. сделали, значит можно.

Генератор зла писал(а):Загляните:
http://opchda.info/index.php?menu=files&id=14
Может, пригодится? Хотя, как по таким данным построить InTouch-тренд?

Это могло бы пригодиться, но нужно ставить historian тогда я полагаю, чтобы строить из SQL базы, а не из собственных файлов InTouch.

Тогда решения не существует. Мех-м ведения исторических трендов в InTouch не допускает запись данных в прошлое. Можете, конечно, "расковырять" структуру файлов LGX/LGH и писать в них вручную. Но идея с WWHistorian мне больше по душе.

Mikhalych писал(а):Не нужно придумывать. Просто SCADA должна обеспечивать работу по существующим современным протоколам телемеханики, например, DNP3.0. А проблемы со связью в системах телемеханики - это более распространенная ситуация, чем цеховое/площадное производство.

Генератор зла писал(а):

Mikhalych писал(а):Что касается систем телемеханики, то внедрения в РФ есть, значит люди нашли решения.

Можете назвать пример и может быть описание данной системы? Я слышал, что используют, но более детально информацию не так просто найти.

У нас телемеханика реализована на InTouch 7.1.
Название системы АДКУ-2000, сейчас переводят на АДКУ-2000+ (от ПКБ "АСУ-Нефть")
Кустовые контроллеры SCADAPack.
На сервере стоит самописный (от ПКБ "АСУ-Нефть") протокол обмена, который собирает данные с контроллеров и складывает их в базу данных MS SQL.
На клиентах стоит самописная прога (от ПКБ "АСУ-Нефть"), которая из БД берёт данные и рисует тренды, InTouch ей для этого совсем не нужен.

bat писал(а):У нас телемеханика реализована на InTouch 7.1.
Название системы АДКУ-2000, сейчас переводят на АДКУ-2000+ (от ПКБ "АСУ-Нефть")
Кустовые контроллеры SCADAPack.
На сервере стоит самописный (от ПКБ "АСУ-Нефть") протокол обмена, который собирает данные с контроллеров и складывает их в базу данных MS SQL.
На клиентах стоит самописная прога (от ПКБ "АСУ-Нефть"), которая из БД берёт данные и рисует тренды, InTouch ей для этого совсем не нужен.

Спасибо за информацию.
Опять таки самописное программное обеспечение (зависимость от разработчика, т.к. свой протокол). Стандартного нет решения (конфигурируемого). и просмотр вне интача, что не очень правильно, имхо, т.к. есть доступ оператора к операционной системе.

У Kepware (www.kepware.com) есть сервер под DNP. Также есть сервер под ODBC. Можно было бы попробовать увязать их. Контроллер -> DNP -> ODBC (например MSSQL) -> через хранимые процедуры в History Blocks WW Historian.

Генератор зла писал(а):У Kepware (http://www.kepware.com) есть сервер под DNP. Также есть сервер под ODBC. Можно было бы попробовать увязать их. Контроллер -> DNP -> ODBC (например MSSQL) -> через хранимые процедуры в History Blocks WW Historian.

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