Умный дом на OpenSCADA
| Автор |
Сообщение |
|
Сообщение создано: 19. 02. 2012 [16:02]
|
|
buldo
Роман Булдыгин
Создатель темы
Зарегистрирован(а) с: 13.02.2012
Сообщения: 6
|
Здравствуйте.
Пишу диплом. Тема - умный дом. В качестве центра умного дома планирую использовать компьютер с OpenSCADA.
Все датчики и исполнительные устройства будут объединены через ZigBee. Компьютер получает доступ к ZigBee через подключённый к нему через виртуальный com порт микроконтроллер.
Я правильно понимаю, что мне необходимо будет с помощью модуля "Пользовательский протокол" придумывать протокол и "учить" исполняющие устройства его понимать?
P.S. Я читал Автоматизация жилого дома - "Умный дом" (HouseSpirit)
|
|
Сообщение создано: 19. 02. 2012 [21:10]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"buldo" wrote:
Все датчики и исполнительные устройства будут объединены через ZigBee. Компьютер получает доступ к ZigBee через подключённый к нему через виртуальный com порт микроконтроллер.
Я правильно понимаю, что мне необходимо будет с помощью модуля "Пользовательский протокол" придумывать протокол и "учить" исполняющие устройства его понимать?
Если учить тогда лучше использовать стандартный протокол, например, ModBus, как было сделано в описанном про "Умный дом" решении.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 20. 02. 2012 [06:26]
|
|
buldo
Роман Булдыгин
Создатель темы
Зарегистрирован(а) с: 13.02.2012
Сообщения: 6
|
На сколько я понял, в том решении scada видела всю сеть датчиков, как одно устройство, подключённое к modbus.
Скажу честно - в ModBus не разбираюсь. Основные знания о нём у меня из википедии. В частности там говориться о минусах ModBus:
Стандарт не позволяет никакой оперативной сигнализации от конечного устройства к мастеру в случае необходимости (прерывания). Нужно ждать своей очереди в опросе. Это существенно ограничивает применимость MODBUS-решений в системах управления реального времени.
Стандарт не позволяет конечным устройствам обмениваться фиксированными данными друг с другом без участия мастера. Это существенно ограничивает применимость MODBUS-решений в системах регулирования реального времени.
Первый довод для меня основной - если произойдёт событие типа протечки, то scada о ней не узнает, пока не опросит соответствующий датчик, или, например, будет задержка между действиями пользователя(например: включение-выключение света) и реакцией SCADA. Конечно - это можно решить более частыми опросами устройств - но это будет означать лишние данные гуляющие по сети, что негативно скажется на энергопотреблении. Если маршрутизатор ZibBee подключен к сети - это не так уж и страшно, но если этот маршрутизатор соединяет удалённые друг от друга участки сети и питается от батареи - то это уже нехорошо.
В связи с этим мой вопрос остается открытым.
|
|
Сообщение создано: 20. 02. 2012 [08:09]
|
|
Avoto
Андрей
Зарегистрирован(а) с: 27.07.2009
Сообщения: 16
|
Роман, вы определите время реакции системы для себя. Все стоит денег, сверхбыстрая реакция - тоже. Если на пол выльется литр воды - ничего страшного в вашей системе5 не произойдет, и стоит ли ради этого делать сверхдорогую систему? Время опроса модбас довольно стандартных - десятки килогерц, вам этого мало?
|
|
Сообщение создано: 20. 02. 2012 [08:20]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 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.
|
|
Сообщение создано: 20. 02. 2012 [09:27]
|
|
buldo
Роман Булдыгин
Создатель темы
Зарегистрирован(а) с: 13.02.2012
Сообщения: 6
|
Просто изначально я собирался добиться того, что бы, например, пользователь провзаимодействовал с системой - и это тут же отобразилось в SCADA. Если не инвертировать участников, то это означает опрос всех датчиков хотя бы раз в секунду. Каждый запрос - это просыпание всех передатчиков в устройстве и лишняя нагрузка на сеть. При этом, как я понимаю, чем больше устройств в сети, тем дольше длится опрос. И в сравнении с этим - отсылка сообщений только при изменении состояний - одно соединение в несколько минут, а иногда и часов.
Поставлю вопрос по иному - смогу ли я средствами OSCADA, например модулем "Пользовательский протокол", реализовать протокол обмена сообщениями с произвольной направленностью(сервер-датчик, датчик-сервер) и произвольной длиной содержимого(планирую использовать xml для хранения тел запросов и ответов).
Или для того, что бы все происходило как я хочу(высокая отзывчивость, xml сообщения) мне проще будет написать собственный модуль?
[Сообщение редактировалось 1 раз(а), в последний раз 20.02.2012 в 09:36.]
|
|
Сообщение создано: 20. 02. 2012 [09:49]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"buldo" wrote:
Просто изначально я собирался добиться того, что бы, например, пользователь провзаимодействовал с системой - и это тут же отобразилось в SCADA. Если не инвертировать участников, то это означает опрос всех датчиков хотя бы раз в секунду.
Зачем? Можно и от 10 секунд до минуты.
"buldo" wrote:
Каждый запрос - это просыпание всех передатчиков в устройстве и лишняя нагрузка на сеть. При этом, как я понимаю, чем больше устройств в сети, тем дольше длится опрос. И в сравнении с этим - отсылка сообщений только при изменении состояний - одно соединение в несколько минут, а иногда и часов.
А текущие значения для Вас уже совсем не интересны? И логику собираетесь реализовывать прямо в датчиках? Крайне Вы не далекоглядны!
"buldo" wrote:
Поставлю вопрос по иному - смогу ли я средствами OSCADA, например модулем "Пользовательский протокол", реализовать протокол обмена сообщениями с произвольной направленностью(сервер-датчик, датчик-сервер) и произвольной длиной содержимого(планирую использовать xml для хранения тел запросов и ответов).
Можно там сделать хоть собственную реализацию ModBus. Однако как только начнёте делать так сразу и увидите, что в значительной степени Ваша проблема не в протоколе!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 20. 02. 2012 [11:04]
|
|
buldo
Роман Булдыгин
Создатель темы
Зарегистрирован(а) с: 13.02.2012
Сообщения: 6
|
"roman" wrote:
Зачем? Можно и от 10 секунд до минуты.
Если бы это была промышленность, возможно действительно так можно было бы сделать. Но современные пользователи любят отзывчивые системы. Не дай Бог что-то будет тормозить или запаздывать - пользователь скажет "фу, какой отстой, я не буду этим пользоваться".
"roman" wrote:
А текущие значения для Вас уже совсем не интересны? И логику собираетесь реализовывать прямо в датчиках? Крайне Вы не далекоглядны!
Про текущие значения: Например температура. Она меняется медленно. Датчик температуры измеряет ее, скажем, каждые 5 минут. Если она не меняется, то он ничего не отправляет через беспроводную сеть. Если она изменилась на градус, то он отправит на сервер со скадой сообщение, что сейчас температура такая-то. Таким образом при измерении температуры раз в пять минут отправка сообщений может происходить раз в час. А до этого события пользователю будет показываться последняя измеренная температура.
Немного не понятно ваше утверждение на счёт логики. Пожалуйста, поясните.
По моим предположениям датчики должны быть способны предоставлять серверу информацию о своем предназначении, доступных командах, и должны выполнять то, что им приказывает сервер.
Например, если это умная розетка, то она должны уметь сказать,например, что она розетка, что у неё два канала, что она может по отдельности включать-выключать каждый канал, что она может мерить сколько ватт проходит через отдельно взятый канал за заданный промежуток времени и если скада прикажет, то она будет отправлять данныйе об этом через заданное время.
|
|
Сообщение создано: 20. 02. 2012 [11:31]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"buldo" wrote:
"roman" wrote:
Зачем? Можно и от 10 секунд до минуты.
Если бы это была промышленность, возможно действительно так можно было бы сделать. Но современные пользователи любят отзывчивые системы. Не дай Бог что-то будет тормозить или запаздывать - пользователь скажет "фу, какой отстой, я не буду этим пользоваться".
Очень смешно.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 20. 02. 2012 [11:39]
|
|
buldo
Роман Булдыгин
Создатель темы
Зарегистрирован(а) с: 13.02.2012
Сообщения: 6
|
"roman" wrote:
"buldo" wrote:
"roman" wrote:
Зачем? Можно и от 10 секунд до минуты.
Если бы это была промышленность, возможно действительно так можно было бы сделать. Но современные пользователи любят отзывчивые системы. Не дай Бог что-то будет тормозить или запаздывать - пользователь скажет "фу, какой отстой, я не буду этим пользоваться".
Очень смешно.
Ну почему же. На данный момент отзывчивость интерфейсов - один из главных маркетинговых козырей продуктов. Например, у бессомнения успешных продуктов фирмы Apple - iPhone и iPad. У процессов графического интерфейса наивысший приоритет исполнения.
Все же, что именно вы хотели сказать о реализации логики в датчиках? Какую именно логику вы подразумевали и что в этом плохого, чем это может обернуться?
|
|
|
