www.InTouch.su

Имеем систему PLC --> InTouch & Historian. Вообщем, такая задача: хранение трендов в контроллере на время потери связи с ПК так, чтобы после восстановления они дописывались в базу (не было провала на тренде).
Мои соображения: берем одну переменную, сохраняем ее значения с определенной периодичностью, например, 1 раз в 100 мсек.
Сохраняем значения в одномерном массиве. А вот как организовать передачу в InTouch & Historian даже не представляю. В какую сторону копать???

Посчитаем грубо. Сохраняем значение 1 раз в сек. Получается 3600 значений в час. 1 значение = 32 бит = 4 байта. 1 час = 14400 байт ~ 14 кбайт. В принципе, немного.
Теперь передача. Имеем часовой архив. Допустим, цикл контроллера 50 мсек. Присваиваем каждый цикл тегу тренда значение из архива. 3600 значений передадим за 3 мин. Это в идеале. В Historian сформируется тренд. Но без привязки ко времени создания архивных значений.

Если сохранять только значение контролируемого параметра (без сохранения даты и времени) - какой тогда толк от такого "тренда" ?

Задачка действительно интересная ).

Во далекие далекие времена самописной скады решали так:
1. контроллер складывает на карту памяти архив - файлики по 5минут.
2. компьютер по ФТП переиодически (раз в 5-10-15 минут) считывает с карты данные и перекладывает в БД.

Как сделать такое с хисториан и возможно ли в принципе - не знаю. По моему у него таблицы закрыты от редактирования...

В принципе, можно из контроллера передать только время начала архива и период измерения сигнала, а затем передавать только накопленные значения. С контроллером все решается. Остается только привязать к Historian. Может, уважаемый Админ просветит нас, возможно это сделать или нет?

To Igor V. Zhdanov:

Проще всего вести записи в контроллере и "переливать" их либо в CSV, либо в БД, а там через MDAS/Select-Insert заносить в Historian. Но хранить данные в контроллере необходимо в правильном формате (DateTime, Value, Quality,...).

Klinkmann_Msk писал(а):To Igor V. Zhdanov:

Проще всего вести записи в контроллере и "переливать" их либо в CSV, либо в БД, а там через MDAS/Select-Insert заносить в Historian. Но хранить данные в контроллере необходимо в правильном формате (DateTime, Value, Quality,...).

Что-то я не понял, ручками что ли?

Возможно автоматизировать перенос данных из архива контроллера в historian?

Можно конечно написать программку, писать в промежуточную базу, потом синхронизировать с historian, но тут уже изобретение велосипеда получается...

Должно быть типовое решение -100% процентов разработчиков так или иначе сталкиваются с этим.

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

В Wonderware Historian данные могут попадать одним из следующих способов:
1. Из I/O server-а по SuiteLink или NetDDE. I/O server - либо какой-нибудь стандартный или написанный ручками на базе тулкита от Wonderware.
2. Из Wonderware Application Server (на самом деле этот способ - просто Wonderware-вская имплементация способа 3 на С++).
3. Из приложения, написанного юзером на С# с использованием Historian SDK. На С/C++ тоже вроде-как можно для юзеров Historian SDK, но не уверен.
4. Через CSV -файлы определенного формата.
5. Через T-SQL INSERT-ы.
6. В версии 10.0 данные могут приходить ещё и от другого (tier-1) historian-a.

beachbear писал(а):В Wonderware Historian данные могут попадать одним из следующих способов:
1. Из I/O server-а по SuiteLink или NetDDE. I/O server - либо какой-нибудь стандартный или написанный ручками на базе тулкита от Wonderware.
2. Из Wonderware Application Server (на самом деле этот способ - просто Wonderware-вская имплементация способа 3 на С++).
3. Из приложения, написанного юзером на С# с использованием Historian SDK. На С/C++ тоже вроде-как можно для юзеров Historian SDK, но не уверен.
4. Через CSV -файлы определенного формата.
5. Через T-SQL INSERT-ы.
6. В версии 10.0 данные могут приходить ещё и от другого (tier-1) historian-a.

т.е. самый работоспособный вариант - написать костыль на C#, который будет забирать из контроллера массив данных и перекладывать в historian?

Что это за контроллер такой, если не секрет,
для которого нет ни Wonderwarного, ни OPCшного I/O сервера, ни даже MDAS-ного "костыля"?
Какова могла бы быть максимальная цена,
которую Ваша организация была бы согласна заплатить,
если подобный продукт был бы завтра доступен в продаже?

beachbear писал(а):Что это за контроллер такой, если не секрет,
для которого нет ни Wonderwarного, ни OPCшного I/O сервера, ни даже MDAS-ного "костыля"?
Какова могла бы быть максимальная цена,
которую Ваша организация была бы согласна заплатить,
если подобный продукт был бы завтра доступен в продаже?

не путайте теплое с мягким. OPC вам напишет любой студент за пару вечеров и ящик пива.

проблема не в том чтобы просто считать данные с контроллера, а нужно считать выборку (массив данных переменной длины), хранящий значения некоторой переменной с меткой времени и положить ее в historian. Т.е. переложить архив из плс в бд.

1. За пару вечеров и ящик пива студент пишет OPC- либо DAS-сервер,
который при восстановлении соединения (но до начала посылки новых данных) пропихивает все накопившиеся
в железке данные в хисториан для сохранения в "late data" тэгах.
Всё остаётся мягким. Студент открывает бизнес по продаже своего сервера.

2. За пару недель инженер-программист пишет приложение, которое периодически соединяется с железкой,
высасывает оттуда накопившиеся данные и посылает их в хисториан как UPDATE,
покрывающий дырку тренда.
Посылать можно как через Historian SDK, который надо покупать,
либо как T-SQL UPDATE через ADO, тогда ничего покупать не надо.
Всё становится тёплым. Инженер-программист ничего не открывает, так как продукт принадлежит работодателю.

3. За один час к задней стенке железки прикручивается болтами атомный неттоп с Windows XP куда ставится Remote IDAS
и разрыва соединения между ними больше гарантированно не бывает.
Разрывы соединения между IDAS-ом и хисторианом полностью компенсируются store/forward механизмом.
Всем сразу тепло и мягко

beachbear

ИМХО
1й С данным функционалом понадобиться уже не пару вечеров, а неделька или более . И где потом только этого студента ловить когда все встанет ). Но как бюджетный вариант - вполне имеет право на жизнь.
2й Я бы проголосовал за этот вариант.
3й вариант вообще не терпит критики. Очень дорого, глупо и ненадежно.

Еще тут возникают определенные требования к контроллерщикам и контроллерам как таковым...