Сторінку заморожено, Автоматизація жилого дому - "Розумний дім" (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 (RU)" — рушій візуалізації для побудови уніфікованих інтерфейсів та представленням (кінцевої візуалізації) за допомогою різних типів графічних інтерфейсів, а також можливістю роботи як сервер інтерфейсів візуалізації.
- Модуль "UI.Vision (RU)" — візуалізатор «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, які описано у таблиці нижче:
| Адреса скрипту | Опис |
| Скрипт Web-сайту (/sub_UI/mod_WebUser/) | |
| up_hs | Головний скрипт Web-сайту, який виконує безпосередній прийом, первинну обробку та формування остаточної відповіді, а саме:
|
| Бібліотека скриптів шаблонів-сторінок та системних процесів (/sub_DAQ/mod_JavaLikeCalc/lib_web/*) | |
| user | Скрипт сторінки-шаблону «Диспетчер користувачів» реалізує функцію формування форми керування користувачами у залежності від прав користувача який увійшов. |
| devices | Скрипт сторінки-шаблону «Диспетчер пристроїв» реалізує функцію формування форми керування пристроями та генерацією порушень за ними для двох типів пристроїв: десятковий та динамічний. |
| devMon | Скрипт формування інтерфейсу моніторингу у формі керування пристроями, які сконфігуровано у «Диспетчері пристроїв». Цей скрипт використовується всіма підсистемами моніторингу пристроїв. |
| alarms | Скрипт задачі періодичної перевірки значень змінних пристроїв на предмет сконфігурованих аварійних ситуацій. Крім безпосереднього формування порушень цей скрипт здійснює розсилання SMS-сповіщень з повідомленням по телефонам користувачів, встановлених для повідомлення з посередництвом SMS. |
| mess | Скрипт сторінки-шаблону «Порушення» реалізує функцію формування переліку активних порушень. |
| report | Скрипт сторінки-шаблону «Звіти» реалізує функцію формування таблиці-звіту з подіями по системі та різним підсистемам за визначений період часу. Звіт одночасно генерується на екрані і у файлі, який можна, за посиланням, завантажити окремо. |
В цілому алгоритм обробки запитів до сторінок наступний (на прикладі 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. Звіти.