Автоматизация жилого дома - "Умный дом" (HouseSpirit)
| Имя: "Умный дом" (HouseSpirit) Начат: 28 03(марта) 2011г Завершён: 12 06(июня) 2011г Расположение: г.Ханты-Мансийск, Россия Участники:  Олег Сидашов, Роман СавоченкоОписание: Реализация проекта автоматизации жилого дома - "Умный дом" (HouseSpirit). Материалы: страница (доступ ограничен) |  |
Введение
Объектом автоматизации является жилой дом, оснащённый оборудованием, подлежащим автоматизации. Система предназначена для автоматизации действий, выполняемых пользователем или обслуживающим персоналом для обеспечения безопасности, комфорта, удобства проживания на объекте автоматизации – в жилом помещении (комната, квартира, частный дом), а также на прилегающей к нему территории (земельный участок, двор, сад).
Система предназначена для решения следующих задач:
- Контроль доступа на объект автоматизации.
- Контроль микроклимата в помещениях.
- Управление освещением на объекте автоматизации.
- Управления водопроводной сетью на объекте автоматизации.
- Управление бытовой и мультимедийной электротехникой на объекте автоматизации.
- Обеспечение удаленного управления, прямого управления (в режиме реального времени), управления по расписанию объектом автоматизации.
- Обнаружение и устранение аварийных ситуаций.
Целями создания системы являются:
- Улучшение качества жизни человека на объекте автоматизации.
- Повышение безопасности объекта автоматизации.
- Снижение затрат на проживание: снижение затрат на электроэнергию, снижение затрат на использование водопроводной сети.
- Снижение временных и физических затрат на операции, выполняемые пользователем на объекте автоматизации.
1. Объект автоматизации
Площадь объекта автоматизации ≈ 300 м2. Температура воздуха в помещениях, предназначенных для установки сервера, датчиков и исполнительных механизмов: от 10 до 25 градусов Цельсия. Температура воздуха вне помещениях, где устанавливаются датчики и исполнительные механизмы: от - 30 до 30 °С.
Уровни загрязненности, влажности, освещенности, шума и ионизирующих излучений соответствуют санитарно-эпидемиологическим требованиям к жилым зданиям и помещениям (САНПИН 2.1.2.1002-00).
На объекте присутствует электромагнитное излучение, индуцируемое бытовыми приборами, а также средствами электронно-вычислительной техники (Bluetooth, Wi-Fi, GSM).
Система “Умный дом. Сервер управления” представляет собой программно-аппаратный модуль, являющийся основным управляющим центром объекта автоматизации. Сервер принимает и обрабатывает сигналы от различных датчиков, формирует и передает сигналы управления исполнительным устройствами, осуществляет связь с пользователем через сеть GSM. Управление системой пользователями осуществляется через веб-интерфейс.
Система “Умный дом. Сервер управления” включает следующие подсистемы:
- Подсистема контроля доступа.
- Подсистема управления освещением.
- Подсистема управления микроклиматом.
- Подсистема управления водопроводной сетью.
- Подсистема управления бытовой и мультимедийной электротехникой.
- Подсистема обработки информации, поступающей с датчиков.
- Подсистема обеспечения интерактивного взаимодействия с пользователем через Web-интерфейс и через сеть GSM.
- Подсистема авторизации.
- Подсистема формирования отчетов.
- Подсистема конфигурации обеспечивает механизмы добавления, извлечения и редактирования информации в используемой базе данных, для работы подсистем 1-8.
Структурная схема системы домовой автоматики приведена на рис.1.
Рис. 1. Структурная схема системы домовой автоматики.
Для управления различным оборудованием жилого дома был разработан концентратор и выстроена беспроводная сеть ZigBee из устройств управления оборудованием. Общий контроль оборудованием, а также предоставление пользовательского Web-интерфейса и иные способы уведомления осуществляются выделенным сервером домовой автоматики. Концентратор сети ZigBee при этом подключается к серверу посредством интерфейса RS-232 и протокола ModBus/RTU. Нарушения в области контроля автоматики высылаются пользователю в виде SMS-уведомлений через подключенный GSM-модем.
Контроллер беспроводной связи имеет следующие технические характеристики:
- Наличие приемо-передатчика ZigBee;
- Скорость передачи данных по протоколу ZigBee не менее 200 Кб/с;
- Наличие USB или COM – порта для соединения с сервером;
- Питание от сети 220 В.
GSM-модуль обладает следующими техническими характеристиками (Siemens TC65):
- Поддержка стандарта GSM-900;
- Наличие USB или COM – порта для соединения с сервером;
- Поддержка AT команд стандарта GSM 07.05 и GSM 07.07;
- Питание от сети 220 В.
Аппаратная часть сервера:
- процессор архитектуры x86_32 или x86_64 (не ниже Intel Core2 Duo);
- оперативная память класса DDR3, в объёме 2ГБ;
- наличие не менее трех USB - портов.
В качестве программного окружения, для выполнения функции автоматизации жилых помещений - "Умный дом" использовано открытую SCADA систему 
OpenSCADA, в окружении которой разработан пользовательский Web-интерфейс "Умный дом", а также реализован опрос и контроль устройствами посредством ZigBee концентратора.
2. Система автоматизации
Система OpenSCADA имеет несколько способов формирования пользовательских интерфейсов визуализации, начиная от интегрированных инструментов разработки типовых интерфейсов контроля различных областей автоматизации и заканчивая низкоуровневыми механизмами библиотек и интерфейсов графических концептов.
В лице интегрированных интерфейсов OpenSCADA содержит:
- Модуль «UI.VCAEngine» - движок визуализации для построения унифицированных интерфейсов и представлением (конечной визуализации) с помощью различных типов графических интерфейсов, а также возможностью работы как сервер интерфейсов визуализации.
- Модуль «UI.Vision» - визуализатор «UI.VCAEngine» и графический интерфейс разработки пользовательских интерфейсов на основе библиотеки построения реактивных графических интерфейсов QT4.
- Модуль «UI.WebVision» - визуализатор «UI.VCAEngine» на основе Web-интерфейсов: XHTML, XML, CSS, JavaScript, DOM и AJAX.
К низкоуровневым механизмам построения пользовательских интерфейсов можно отнести любые другие графические библиотеки, в которых есть инструменты быстрой разработки пользовательских интерфейсов. При этом кооперация с OpenSCADA производится как с источником данных и интерфейсом унифицированного управления оборудованием по различным протоколам.
Для предоставления возможности свободного формирования пользовательских Web - интерфейсов, непосредственно в окружении OpenSCADA, предусмотрен модуль «UI.WebUser». В целом OpenSCADA содержит все основные функции типового Web-сервера, а именно:
- Приём клиентских подключений по стандартным транспортным протоколам: TCP, UDP, Unix, а так-же защищённым соединениям SSL и TLS.
- Поддержка основных функций протокола HTTP, в объёме запросов GET и POST.
- Динамическое формирование пользовательского контента посредством внутреннего JavaScript (JavaLikeCalc) языка в виде потоков с содержимым: языков HTML, XHTML, XML, CSS, JavaScript, изображений различных форматов и т. д.
Следовательно, для построения произвольного пользовательского интерфейса контроля достаточно иметь инсталлированную систему OpenSCADA с модулями: Transport.Sockets?, Transport.SSL, Protocol.HTTP и UI.WebUser.
2.1. Структура и размещение файлов
С целью уменьшения нагрузки на полностью динамическое формирование пользовательского интерфейса, а также для упрощения последующего расширения и модификации стиля Web-интерфейс был поделён на статическую и динамическую части.
Статическая часть представляет из себя набор шаблонных HTML-файлов, с метками размещения динамики, и ресурсные файлы: CSS, JavaScript и изображения. В целом, статическая часть представлена файлами, которые описаны в таблице ниже:
| Файл | Описание |
| HTML-шаблоны (HouseSpirit/Web/*) | |
| main.html | Главный шаблон пользовательского интерфейса. Содержит общий интерфейс пользователя с меткой расположения содержимого страниц « |
| auth.html | Шаблон интерфейса авторизации с меткой расположения содержимого « Создан для использования модулем протокола HTTP (/sub_Protocol/mod_HTTP). |
| access.html | Шаблон контроля доступа. |
| temperature.html | Шаблон управления микроклиматом. |
| light.html | Шаблон управления освещением. |
| water.html | Шаблон управления водопроводной подсистемой. |
| tech.html | Шаблон управления электронной и бытовой техникой. |
| friend.html | Шаблон управления пользовательскими устройствами. |
| user.html | Шаблон диспетчера пользователей. |
| devices.html | Шаблон диспетчера устройств. |
| loginError.html | Страница сообщения ошибки аутентификации или её отсутствия. |
| mess.html | Шаблон сообщений активных аварийных ситуаций. |
| report.html | Шаблон формирования отчётов об нарушениях, действиях и системных сообщениях. |
| welcome.html | Страница приветствия, отображаемая по умолчанию в поле контента. |
| Ресурсы (HouseSpirit/Web/res/*) | |
| stylesheet.css | Каскадные таблицы стилей всего пользовательского интерфейса. |
| main.js | JavaScript код главного шаблона, для счётчика времени и сеанса. |
| devMon.js | JavaScript код реализации динамического AJAX интерфейса мониторинга устройств подсистем. |
| access.png, accesson.png | Изображения подсистемы контроля доступа. |
| temperature.png, temperatureon.png | Изображения подсистемы управления микроклиматом. |
| light.png, lighton.png | Изображения подсистемы управления освещением. |
| water.png, wateron.png | Изображения управления водопроводной подсистемой. |
| tech.png, techon.png | Изображения подсистемы управления электронной и бытовой техникой. |
| friend.png, friendon.png | Изображения подсистемы управления пользовательскими устройствами. |
| user.png, useron.png | Изображения диспетчера пользователей. |
| devices.png, deviceson.png | Изображения диспетчера устройств. |
| report.png, reporton.png | Изображение формирования отчётов об нарушениях, действиях и системных сообщениях. |
| help.png, helpon.png | Изображения страницы помощи. |
| HouseSpirit.ico | Иконка Web-интерфейса. |
| hd_l.png, hd_r.png | Левая и правая части заголовка. |
| select_l.png, select_r.png | Изображения фона выбранного элемента меню слева и справа. |
| space_l.png, space_r.png | Изображения свободного пункта меню слева и справа. |
| status_l.png, status_r.png status_edge.png | Изображения строки статуса. |
| Файлы отчётов (HouseSpirit/Web/reports/*) | |
| rep_{user}.html | Последний отчёт пользователя user. |
Динамическая часть реализована скриптами OpenSCADA на внутреннем языке JavaLikeCalc, которые описаны в таблице ниже:
В целом алгоритм обработки запросов к страницам следующий (на примере http://localhost:10002/WebUser/temperature?script=devMon):
- запрос поступает в скрипт /sub_UI/mod_WebUser/hs из транспорта /sub_Transport/mod_Sockets/in_WEB_1, посредством модуля протокола Protocol.HTTP;
- грузится файл шаблона temperature.html;
- осуществляется поиск скрипта страницы devMon (/sub_DAQ/mod_JavaLikeCalc/lib_web/devMon). Если аргумент script отсутствует то осуществляется поиск скрипта по имени страницы (/sub_DAQ/mod_JavaLikeCalc/lib_web/temperature);
- осуществляется передача шаблона страницы в найденный скрипт для формирования динамики;
- результат выполнения скрипта страницы помещается в главный шаблон;
- если скрипт страницы не обнаруживается, то шаблон страницы помещает её содержимое прямо в главный шаблон.
2.2. Менеджер устройств
Менеджер устройств доступен только суперпользователю и формирует форму редактирования (рис.2), добавления и удаления устройств двух типов: бинарный и десятичный.
Рис. 2. Менеджер устройств.
Создаваемые устройства непосредственно помещаются в список атрибутов параметра конкретно взятой подсистемы контроллера «ZigBee» модуля источника данных ModBus (/sub_DAQ/mod_ModBus/cntr_ZegBee/). Формат записи атрибута имеет вид:
- «R:0:r:cond:Кондиционер:bin:10:Включен:лючен:(120|100)» - для бинарного датчика:
- R — регистр ModBus;
- 0 — адрес регистра ModBus;
- r — только чтение;
- cond — идентификатор атрибута-датчика;
- Кондиционер — наименование датчика;
- bin — тип датчика - «Бинарный»;
- 10 — первое значение;
- Включен — имя первого значения;
- 0 — второе значение;
- Выключен — имя второго значения;
- (120|100) — координаты размещения ({x}|{y}) датчика на схеме жилого помещения.
- «R:3:rw:а в гостинной 1:dec:град. С:y=2*x;:(120|100)» - для десятичного датчика:
- rw — только чтение;
- dec — тип датчика - «Десятичный»;
- град. С — единица измерения переменной;
- y=2*x; — формула пересчёта считанной переменной для отображения;
- (120|100) — координаты размещения ({x}|{y}) датчика на схеме жилого помещения.
Кроме непосредственно датчиков осуществляется конфигурация и формирование нарушений в виде текста процедуры. Программа формирования помещается в атрибут «var» параметра контроллера нарушений /sub_DAQ/mod_JavaLikeCalc/cntr_alarms/prm_rules. Атрибут «var» содержит XML дерево вида:
<ALARMS>
<it id = "temperature.cond1">
if(x<10) err = "Низкая температура: "+x+" < 10";
</it>
</ALARMS>
В соответствии с этим XML-деревом осуществляется формирование нарушений и отправка SMS-уведомлений подписанным пользователям в задаче контроллера /sub_DAQ/mod_JavaLikeCalc/cntr_alarms, которая исполняется с периодом 1 минута.
SMS-уведомления отсылаются через последовательный транспорт /sub_Transport/mod_Serial/out_GSM и посредством пользовательского SMS-протокола (/sub_Protocol/mod_UserProtocol/up_SMS).
Предусмотрена также функция отложенной выдачи управляющего воздействия. Для этого пользователь устанавливает нужное время, в виде: {Min}:{Sec}. Обработка отложенного управления осуществляется в контроллере /sub_DAQ/mod_JavaLikeCalc/cntr_timers посредством установки атрибута «var» параметра «rules» запросами в виде XML дерева:
<TIMERS>
<timer id="temperature.tGhost1" tm="60" user="root">20</timer>
<timer id="temperature.cond1" tm="10" user="root">0</timer>
</TIMERS>
2.3. Подсистемы
Все подсистемы визуализации обслуживаются скриптом /sub_DAQ/mod_JavaLikeCalc/lib_web/devMon. В этом скрипте осуществляется обработка запросов от скрипта динамической визуализации Web-браузера и передача ему данных об устройствах подсистемы, необходимых для визуализации (рис.3). Данные об устройствах передаются в соответствии с правами доступа вошедшего пользователя.
Рис. 3. Управление подсистемой.
Конфигурация датчиков читается из параметра, соответствующего подсистеме контроллера «ZigBee» (/sub_DAQ/mod_ModBus/cntr_ZegBee). Значения читаются и записываются в атрибуты датчиков этих параметров или через контроллер отложенного управления.
Задача контроллера «ZigBee» исполняется с периодом 1 секунда, в процессе чего осуществляется запрос текущих значений всех сконфигурированных датчиков. Запись значений осуществляется по факту модификации независимо от задачи периодического опроса или через контроллер отложенного управления в случае установки ненулевого времени таймера.
Связь контроллера «ZigBee» осуществляется через последовательный исходящий транспорт /sub_Transport/mod_Serial/out_ZegBee.
2.4. Менеджер пользователей
Менеджер пользователей (рис.4) предназначен для создания, удаления и редактирования учётных записей обычных пользователей.
Рис. 4. Менеджер пользователей.
Пользователи условно делятся на администраторов и простых пользователей. Идентификация пользователя как администратора, в системе OpenSCADA, осуществляется включением его в группу «WebRoot» (/sub_Security/grp_WebRoot). Обычный пользователь включается в группу «Web» (/sub_Security/grp_Web).
В системе OpenSCADA у каждого пользователя (/sub_Security/usr_test1/) есть текстовое поле описания, которое в данном случае служит для хранения его специализированных параметров в виде:
TEL: +380679859815
SMS: true
Report: false
sub_access: --
sub_friend: --
sub_light: --
sub_tech: --
sub_temperature: rw
sub_water: --
В случае с администратором записи прав доступа к подсистемам отсутствуют, но присутствуют общесистемные параметры вроде времени жизни сеанса (/sub_Protocol/mod_HTTP).
2.5. Сообщения
Список сообщений формируется, исходя из перечня активных нарушений по их категории «ALARM:House:*» в виде таблицы с временем, категорией, уровнем и сообщением нарушения (рис.5).
Рис. 5. Сообщения.
2.6. Отчёты
В формировании отчёта указывается временной диапазон и выбираются типы сообщений. Предусмотрена генерация сообщений для типов:
- «Системные события» — включает сообщения об авторизации и выходе пользователей на ресурсе посредством категории сообщений «
- «События подсистем мониторинга и управления» — включает нарушения и запись новых значений по датчикам посредством категории сообщений «
Протокол формируется в виде таблицы (рис.6) с временем, категорией, уровнем и сообщением нарушения, которая также записывается в отдельный файл отчёта, в последствии доступный по ссылке для отдельного открытия.
Рис. 6. Отчёты.
Action source page doesn't exist yet(/Using / Smart House / matrials?)
Ссылки