|
Written on: 20. 02. 2012 [11:51]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3747
|
"buldo" wrote:
Ну почему же. На данный момент отзывчивость интерфейсов - один из главных маркетинговых козырей продуктов. Например, у бессомнения успешных продуктов фирмы Apple - iPhone и iPad. У процессов графического интерфейса наивысший приоритет исполнения.
Сбор данных фактически никакого отношения к отзывчивости интерфейса визуализации не имеет!
Пример глупый!
"buldo" wrote:
Все же, что именно вы хотели сказать о реализации логики в датчиках? Какую именно логику вы подразумевали и что в этом плохого, чем это может обернуться?
Сами увидите, просто мне больше не интересно объяснять истину!
Learn, learn and learn better than work, work and work.
|
|
Written on: 20. 02. 2012 [11:57]
|
|
buldo
Роман Булдыгин
Topic creator
registered since: 13.02.2012
Posts: 6
|
Возможно пример и не удачен.
"roman" wrote:
Сами увидите, просто мне больше не интересно объяснять истину!
Вы все же не ответили на вопрос про логику. Что вы имеете в виду? Не превращать датчики в мини ПЛК? Не давать датчикам мозгов совсем, а работать с ними как с чем то. что содержит регистры памяти? Или что-то иное?
|
|
Written on: 21. 02. 2012 [10:42]
|
|
almaz
Almaz Karimov
Contributor
registered since: 25.09.2008
Posts: 516
|
"buldo" wrote:
Все датчики и исполнительные устройства будут объединены через ZigBee. Компьютер получает доступ к ZigBee через подключённый к нему через виртуальный com порт микроконтроллер. А этот микроконтроллер предоставляет некий протокол обмена поверх ZigBee. Лучше бы выбрать самому предоставляемый протокол, совместимый с OpenSCADA, чем приспосабливать OpenSCADA к неподдерживаемому протоколу.
Например, шлюз ModBus - ZigBee:
http://www.modbus.org/viewdevice.php?id=366
Или сразу сеть сбора данных:
http://www.icpdas.com.tw/product/solutions/industrial_wireless_communication/wireless_solutions/wireless_selection.html#d
"buldo" wrote:
мне проще будет написать собственный модуль
"buldo" wrote:
Я правильно понимаю, что мне необходимо будет с помощью модуля "Пользовательский протокол" придумывать протокол и "учить" исполняющие устройства его понимать? Если этот микроконтроллер предоставляет прямой доступ к протоколу передачи ZigBee, то можно написать модуль OpenSCADA на с++ (что лучше) или протокол на ява-подобном (что проще). Только при использовании протокола ZigBee напрямую в свободных системах есть юридическая проблема. Как бы альянс ZigBee разрешает использовать протокол напрямую только членам альянса за определённые денежные отчисления и договорённости:
http://freaklabs.org/index.php/Blog/Zigbee/Zigbee-Linux-and-the-GPL.html
http://ru.wikipedia.org/wiki/Zigbee#.D0.9B.D0.B8.D1.86.D0.B5.D0.BD.D0.B7.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5
"buldo" wrote:
Скажу честно - в ModBus не разбираюсь. Основные знания о нём у меня из википедии. В частности там говориться о минусах ModBus:
Стандарт не позволяет никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Нужно ждать своей очереди в опросе. Это существенно ограничивает применимость MODBUS-решений в системах управления реального времени.
Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость MODBUS-решений в системах регулирования реального времени. За счёт скорости обмена, например, по ModBus/TCP и грамотного размещения серверных и клиентских портов обмена в сети вполне можно обойти эти недостатки-ограничения базового ModBus. OpenSCADA позволяет строить сети обработки данных с произвольным размещением серверных и клиентских частей протокола на разных узлах сети.
"buldo" wrote:
Первый довод для меня основной - если произойдёт событие типа протечки, то scada о ней не узнает, пока не опросит соответствующий датчик, или, например, будет задержка между действиями пользователя(например: включение-выключение света) и реакцией SCADA. Если OpenSCADA опрашивает датчики, обрабатывает данные и выводит управляющие сигналы, например 10 раз в секунду, то время реакции составит 100 миллисекунд, в то время как в сетях ZigBee реакция может растянуться на секунду и более в зависимости от количества узлов и скорости передачи.
"buldo" wrote:
Конечно - это можно решить более частыми опросами устройств - но это будет означать лишние данные гуляющие по сети, что негативно скажется на энергопотреблении. Время реакции или период ввода-вывода и обработки данных более приоритетный параметр, чем энергосбережение. Иначе, сберегая энергию, система может не выполнить возложенных на неё задач. Можно, конечно, организовать работу по событиям в сети для оптимального соотношения производительность-энергопотребление. OpenSCADA это позволяет сделать.
"buldo" wrote:
Все же, что именно вы хотели сказать о реализации логики в датчиках? Какую именно логику вы подразумевали и что в этом плохого, чем это может обернуться? Логику работы лучше делать в одной системе программирования. И это OpenSCADA. Зоопарк различных программных средств для разных ПЛК, датчиков и т.д. ни к чему хорошему не ведёт.
"buldo" wrote:
Вы все же не ответили на вопрос про логику. Что вы имеете в виду? Не превращать датчики в мини ПЛК? Не давать датчикам мозгов совсем, а работать с ними как с чем то. что содержит регистры памяти? Или что-то иное? Если в датчики встроить энергоэффективные мини- микро- компьютеры с OpenSCADA вполне можно возложить часть работы по обработке информации на эти датчики.
http://ru.wikipedia.org/wiki/Raspberry_Pi
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
