EnglishУкраїнськаmRussian
Login/New
Topic with many replies

Умный дом на OpenSCADA


| 1 | 2 | Last
Author Message
Written on: 19. 02. 2012 [16:02]
buldo
Роман Булдыгин
Topic creator
registered since: 13.02.2012
Posts: 6
Здравствуйте.
Пишу диплом. Тема - умный дом. В качестве центра умного дома планирую использовать компьютер с OpenSCADA.
Все датчики и исполнительные устройства будут объединены через ZigBee. Компьютер получает доступ к ZigBee через подключённый к нему через виртуальный com порт микроконтроллер.

Я правильно понимаю, что мне необходимо будет с помощью модуля "Пользовательский протокол" придумывать протокол и "учить" исполняющие устройства его понимать?

P.S. Я читал Автоматизация жилого дома - "Умный дом" (HouseSpirit)
Written on: 19. 02. 2012 [21:10]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"buldo" wrote:

Все датчики и исполнительные устройства будут объединены через ZigBee. Компьютер получает доступ к ZigBee через подключённый к нему через виртуальный com порт микроконтроллер.

Я правильно понимаю, что мне необходимо будет с помощью модуля "Пользовательский протокол" придумывать протокол и "учить" исполняющие устройства его понимать?

Если учить тогда лучше использовать стандартный протокол, например, ModBus, как было сделано в описанном про "Умный дом" решении.

Learn, learn and learn better than work, work and work.
Written on: 20. 02. 2012 [06:26]
buldo
Роман Булдыгин
Topic creator
registered since: 13.02.2012
Posts: 6
На сколько я понял, в том решении scada видела всю сеть датчиков, как одно устройство, подключённое к modbus.
Скажу честно - в ModBus не разбираюсь. Основные знания о нём у меня из википедии. В частности там говориться о минусах ModBus:
Стандарт не позволяет никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Нужно ждать своей очереди в опросе. Это существенно ограничивает применимость MODBUS-решений в системах управления реального времени.
Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость MODBUS-решений в системах регулирования реального времени.

Первый довод для меня основной - если произойдёт событие типа протечки, то scada о ней не узнает, пока не опросит соответствующий датчик, или, например, будет задержка между действиями пользователя(например: включение-выключение света) и реакцией SCADA. Конечно - это можно решить более частыми опросами устройств - но это будет означать лишние данные гуляющие по сети, что негативно скажется на энергопотреблении. Если маршрутизатор ZibBee подключен к сети - это не так уж и страшно, но если этот маршрутизатор соединяет удалённые друг от друга участки сети и питается от батареи - то это уже нехорошо.
В связи с этим мой вопрос остается открытым.
Written on: 20. 02. 2012 [08:09]
Avoto
Андрей
registered since: 27.07.2009
Posts: 16
Роман, вы определите время реакции системы для себя. Все стоит денег, сверхбыстрая реакция - тоже. Если на пол выльется литр воды - ничего страшного в вашей системе5 не произойдет, и стоит ли ради этого делать сверхдорогую систему? Время опроса модбас довольно стандартных - десятки килогерц, вам этого мало?
Written on: 20. 02. 2012 [08:20]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"buldo" wrote:

На сколько я понял, в том решении scada видела всю сеть датчиков, как одно устройство, подключённое к modbus.

Никто не мешает видеть их и по отдельности.

"buldo" wrote:

Скажу честно - в ModBus не разбираюсь. Основные знания о нём у меня из википедии. В частности там говориться о минусах ModBus:
Стандарт не позволяет никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Нужно ждать своей очереди в опросе. Это существенно ограничивает применимость MODBUS-решений в системах управления реального времени.

Практически, это и в промышленности нужно крайне редко, поскольку связано с типично низкой скоростью переходных процессов. Что тут уже говорить про "Умный дом"! :) Кроме того любой протокол работающий по обычной схеме "Запрос" -> "Ответ" можно использовать и для этой, описанной как недостаток, функции просто инвертировав участников, т.е поменяв инициатора на клиентов, если это конечно не чистая последовательная шина где в таком случае неизбежны коллизии и увеличение времени передачи до ещё худших параметров!

"buldo" wrote:

Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость MODBUS-решений в системах регулирования реального времени.

Инверсия, выше!

"buldo" wrote:

Первый довод для меня основной - если произойдёт событие типа протечки, то scada о ней не узнает, пока не опросит соответствующий датчик, или, например, будет задержка между действиями пользователя(например: включение-выключение света) и реакцией SCADA.

Систем управления наверное никогда не видели. :)
Вы знаете какая у Вас скорость реакции на событие? От 10 секунд до часов (с просонья). А теперь возьмите и посчитайте сколько раз пройдёт опрос устройств на их скорости обмена и тем самым сколько раз Вы успеете увидеть событие перед тем как успеете что нибудь сделать!

Learn, learn and learn better than work, work and work.
Written on: 20. 02. 2012 [09:27]
buldo
Роман Булдыгин
Topic creator
registered since: 13.02.2012
Posts: 6
Просто изначально я собирался добиться того, что бы, например, пользователь провзаимодействовал с системой - и это тут же отобразилось в SCADA. Если не инвертировать участников, то это означает опрос всех датчиков хотя бы раз в секунду. Каждый запрос - это просыпание всех передатчиков в устройстве и лишняя нагрузка на сеть. При этом, как я понимаю, чем больше устройств в сети, тем дольше длится опрос. И в сравнении с этим - отсылка сообщений только при изменении состояний - одно соединение в несколько минут, а иногда и часов.

Поставлю вопрос по иному - смогу ли я средствами OSCADA, например модулем "Пользовательский протокол", реализовать протокол обмена сообщениями с произвольной направленностью(сервер-датчик, датчик-сервер) и произвольной длиной содержимого(планирую использовать xml для хранения тел запросов и ответов).

Или для того, что бы все происходило как я хочу(высокая отзывчивость, xml сообщения) мне проще будет написать собственный модуль?

[This article was edited 1 times, at last 20.02.2012 at 09:36.]
Written on: 20. 02. 2012 [09:49]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"buldo" wrote:

Просто изначально я собирался добиться того, что бы, например, пользователь провзаимодействовал с системой - и это тут же отобразилось в SCADA. Если не инвертировать участников, то это означает опрос всех датчиков хотя бы раз в секунду.

Зачем? Можно и от 10 секунд до минуты.

"buldo" wrote:

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

А текущие значения для Вас уже совсем не интересны? И логику собираетесь реализовывать прямо в датчиках? Крайне Вы не далекоглядны!

"buldo" wrote:

Поставлю вопрос по иному - смогу ли я средствами OSCADA, например модулем "Пользовательский протокол", реализовать протокол обмена сообщениями с произвольной направленностью(сервер-датчик, датчик-сервер) и произвольной длиной содержимого(планирую использовать xml для хранения тел запросов и ответов).

Можно там сделать хоть собственную реализацию ModBus. Однако как только начнёте делать так сразу и увидите, что в значительной степени Ваша проблема не в протоколе!

Learn, learn and learn better than work, work and work.
Written on: 20. 02. 2012 [11:04]
buldo
Роман Булдыгин
Topic creator
registered since: 13.02.2012
Posts: 6
"roman" wrote:
Зачем? Можно и от 10 секунд до минуты.

Если бы это была промышленность, возможно действительно так можно было бы сделать. Но современные пользователи любят отзывчивые системы. Не дай Бог что-то будет тормозить или запаздывать - пользователь скажет "фу, какой отстой, я не буду этим пользоваться".
"roman" wrote:
А текущие значения для Вас уже совсем не интересны? И логику собираетесь реализовывать прямо в датчиках? Крайне Вы не далекоглядны!

Про текущие значения: Например температура. Она меняется медленно. Датчик температуры измеряет ее, скажем, каждые 5 минут. Если она не меняется, то он ничего не отправляет через беспроводную сеть. Если она изменилась на градус, то он отправит на сервер со скадой сообщение, что сейчас температура такая-то. Таким образом при измерении температуры раз в пять минут отправка сообщений может происходить раз в час. А до этого события пользователю будет показываться последняя измеренная температура.

Немного не понятно ваше утверждение на счёт логики. Пожалуйста, поясните.

По моим предположениям датчики должны быть способны предоставлять серверу информацию о своем предназначении, доступных командах, и должны выполнять то, что им приказывает сервер.
Например, если это умная розетка, то она должны уметь сказать,например, что она розетка, что у неё два канала, что она может по отдельности включать-выключать каждый канал, что она может мерить сколько ватт проходит через отдельно взятый канал за заданный промежуток времени и если скада прикажет, то она будет отправлять данныйе об этом через заданное время.
Written on: 20. 02. 2012 [11:31]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"buldo" wrote:

"roman" wrote:
Зачем? Можно и от 10 секунд до минуты.

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

Очень смешно.

Learn, learn and learn better than work, work and work.
Written on: 20. 02. 2012 [11:39]
buldo
Роман Булдыгин
Topic creator
registered since: 13.02.2012
Posts: 6
"roman" wrote:

"buldo" wrote:

"roman" wrote:
Зачем? Можно и от 10 секунд до минуты.

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

Очень смешно.


Ну почему же. На данный момент отзывчивость интерфейсов - один из главных маркетинговых козырей продуктов. Например, у бессомнения успешных продуктов фирмы Apple - iPhone и iPad. У процессов графического интерфейса наивысший приоритет исполнения.

Все же, что именно вы хотели сказать о реализации логики в датчиках? Какую именно логику вы подразумевали и что в этом плохого, чем это может обернуться?
| 1 | 2 | Last



14840