English
Українська

---

Страница заморожена, актуальная тут.

Автоматизация жилого дома - "Умный дом" (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. Управление системой пользователями осуществляется через веб-интерфейс.

Система “Умный дом. Сервер управления” включает следующие подсистемы:

1. Подсистема контроля доступа.
2. Подсистема управления освещением.
3. Подсистема управления микроклиматом.
4. Подсистема управления водопроводной сетью.
5. Подсистема управления бытовой и мультимедийной электротехникой.
6. Подсистема обработки информации, поступающей с датчиков.
7. Подсистема обеспечения интерактивного взаимодействия с пользователем через Web-интерфейс и через сеть GSM.
8. Подсистема авторизации.
9. Подсистема формирования отчетов.
10. Подсистема конфигурации обеспечивает механизмы добавления, извлечения и редактирования информации в используемой базе данных, для работы подсистем 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 и изображения. В целом, статическая часть представлена файлами, которые описаны в таблице ниже:

Динамическая часть реализована скриптами 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 дерево вида:

В соответствии с этим 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 дерева:

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/) есть текстовое поле описания, которое, в данном случае, служит для хранения его специализированных параметров в виде:

В случае с администратором записи прав доступа к подсистемам отсутствуют, но присутствуют общесистемные параметры вроде времени жизни сеанса (/sub_Protocol/mod_HTTP).

2.5. Сообщения

Список сообщений формируется, исходя из перечня активных нарушений по их категории «ALARM:House:*» в виде таблицы с временем, категорией, уровнем и сообщением нарушения (рис.5).

Рис. 5. Сообщения.

2.6. Отчёты

В формировании отчёта указывается временной диапазон и выбираются типы сообщений. Предусмотрена генерация сообщений для типов:

• «Системные события» — включает сообщения об авторизации и выходе пользователей на ресурсе, посредством категории сообщений «
• «События подсистем мониторинга и управления» — включает нарушения и запись новых значений по датчикам, посредством категории сообщений «

Протокол формируется в виде таблицы (рис.6) с временем, категорией, уровнем и сообщением нарушения, которая также записывается в отдельный файл отчёта, в последствии доступный по ссылке для отдельного открытия.

Рис. 6. Отчёты.

Ссылки