|
Written on: 02. 07. 2013 [08:13]
|
|
unkier
Дмитрий Шаповалов
Topic creator
registered since: 08.06.2012
Posts: 6
|
есть в данный момент проект экспериментальный. его суть в отслеживании местоположения подвижных объектов и сбора с них разнообразных данных. тут сразу есть нюанс. связь с объектами по радио и она может пропадать(и это нормально). когда смотрели какими протоколами сопрягаться с объектом, сразу на глаза попался opc ua. там вроде как есть профайлы для архивных данных ( hda ). поглядели какие есть скады с поддержкой этого протокола и выбрали ignition. для данных идущих в реальном времени проблем нет, они отображаются и пишутся в базу данных. но когда связь пропадает, в базе данных образуются разрывы в данных.предполагалось что скада при помощи механизмов в протоколе opc ua сможет эти разрывы в данных восстанавливать читая данные из архива на удаленном устройстве. но не тут то было. оказалось что эта скада поддерживает только данные реального времени ( da ), а для того чтобы данные с удаленных устройств архивировались и не пропадали, предполагается на том конце ставить персоналку с куском скады который по ненадежному каналу сопрягается с сервером скады и уже эта связка позволяет при потере связи восстанавливать архивные данные с удаленного устройства. нам это не подходит, у нас очень компактный прибор.
собственно вопрос: в данном проекте поддержка opc ua присутствует, архивных данных тоже. можно ли каким то образом реализовать такую функциональность чтобы сервер скады сам понимал о провалах в архивах и сам восстанавливал эти архивы читая данные с удаленных устройств ? и вообще стоит ли в таком случае применять скаду или наши желания настолько нетипичны что проще сделать рукописное решение с 0 ? прибор с которого собираются данные полностью наша разработка и никаких ограничений по протоколам и технологиям нет, можем сделать как угодно чтобы скаде было удобно.
заранее благодарен.
|
|
Written on: 02. 07. 2013 [10:20]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"unkier" wrote:
есть в данный момент проект экспериментальный. его суть в отслеживании местоположения подвижных объектов и сбора с них разнообразных данных. тут сразу есть нюанс. связь с объектами по радио и она может пропадать(и это нормально). когда смотрели какими протоколами сопрягаться с объектом, сразу на глаза попался opc ua. там вроде как есть профайлы для архивных данных ( hda ). поглядели какие есть скады с поддержкой этого протокола и выбрали ignition.
Если "ignition", то зачем писать сюда?
Если OpenSCADA то чем DAQGate не устроил?
Если имено OPC-UA то почитайте о его реализации у OpenSCADA: http://wiki.oscada.org/Doc/OPCUA . Где Вы увидете, что это сервис работы с историей, который по объективным причинам сейчас не реализован. Однако если Вам это реально нужно, то можете заказать, предоставить оборудование с поддержкой этого сервиса в OPC-UA или сами добавить его реализацию и предаставить патчи проекту.
"unkier" wrote:
... а для того чтобы данные с удаленных устройств архивировались и не пропадали, предполагается на том конце ставить персоналку с куском скады который по ненадежному каналу сопрягается с сервером скады и уже эта связка позволяет при потере связи восстанавливать архивные данные с удаленного устройства. нам это не подходит, у нас очень компактный прибор.
С таким-же успехом этот прибор должен предоставлять OPC-UA + сервис работы с историей, что для "немощных" приборов тоже или недоступно или очень специфично и дорого. Вообще насколько компактный?
"unkier" wrote:
собственно вопрос: в данном проекте поддержка opc ua присутствует, архивных данных тоже. можно ли каким то образом реализовать такую функциональность чтобы сервер скады сам понимал о провалах в архивах и сам восстанавливал эти архивы читая данные с удаленных устройств ?
Ответ в самом начале, где DAQ.DAQGate уже такое может, а DAQ.OPC_UA потенциально может.
"unkier" wrote:
и вообще стоит ли в таком случае применять скаду или наши желания настолько нетипичны что проще сделать рукописное решение с 0 ? прибор с которого собираются данные полностью наша разработка и никаких ограничений по протоколам и технологиям нет, можем сделать как угодно чтобы скаде было удобно.
Ставьте на приборе OpenSCADA и используйте DAQ.DAQGate. Или реализуйте нечто вроде ModBus-сервера с расширенной функцией доступа к архивам, а затем эту-же функцию ModBus реализуйте в OpenSCADA, что дольше, но если прибор сильно слаб наверное единственное решение.
Learn, learn and learn better than work, work and work.
|
|
Written on: 02. 07. 2013 [12:18]
|
|
unkier
Дмитрий Шаповалов
Topic creator
registered since: 08.06.2012
Posts: 6
|
спасибо за быстрый ответ !
поглядел информацию и похоже DAQGate то что нужно.
запустить на нашей железке будет вполне реально. будем думать.
|
|
Written on: 04. 07. 2013 [05:47]
|
|
pentagon128
Руслан Кучерявый
registered since: 15.11.2011
Posts: 102
|
Лет 10 назад приходилось решать подобную задачу для стационарных объектов. На каждом объекте свой контроллер с массивом исторических данных. Решение заключалось в периодических попытках обмена с выборкой данных с небольшим перехлёстом периода запрашиваемых данных. Данные поступали в БД АРМА ведущего обмен с контроллерами содержащую локальную копию исторических данных контроллеров отсортированную по Primary key - первичному ключу. Далее на верхнем уровне работает SQL сервер который в свою глобальную БД по объектам синхронизирует данные локальных копий. При этом SQL сервер вначале делает разностный запрос по Primary key на 2 копии данных и определяет разностную таблицу. Далее разностная таблица перекачивается в БД SQL сервера. Вся дальнейшая обработка (АРМЫ пользователей) - уже работают с БД SQL сервера - она получается без пропусков. Минус данного решения - не было реализовано формирование запроса к контроллеру на основе анализа данных существующих в БД АРМ-а ведущего обмен. Но эту задачу можно решить на Open Scada если данные писать в БД поддерживающую SQL запросы. Для этого в контроллере должен крутиться движок БД поддерживающий SQL. Сами данные можно получать с помощью Open Scada работающей например в контроллере.
[This article was edited 1 times, at last 04.07.2013 at 05:50.]
|
|
Written on: 04. 07. 2013 [07:44]
|
|
unkier
Дмитрий Шаповалов
Topic creator
registered since: 08.06.2012
Posts: 6
|
мы сейчас решили попробовать вариант который не будет требовать переделок существующего софта. идея такова, реализовать что то вроде modbus прокси сервера, который будет понимать контекст данных и складировать их в базу данных. система сама будет понимать о дырках в архивах и сама будет считывать недостающие данные с удалённых узлов. при этом также будет являться modbus сервером и будет предоставлять все те же мгновенные данные для старой скады. скада будет работать с базой данных напрямую, для создания отчетов. и вообще такая штука мне кажется полезной, можно любой прибор поддерживающих модбас подключать через такой прокси и получать архивирование данных не меняя старый интерфейс обмена с устройством.
|
