|
Автоматизація жилого дому — "Розумний дім" (HouseSpirit) |
|
Об'єктом автоматизації є жилий дім, оснащений обладнанням, яке підлягає автоматизації. Система призначена для автоматизації дій, виконуваних користувачем або обслуговуючим персоналом для забезпечення безпеки, комфорту, зручності проживання на об'єкті автоматизації — у жилому приміщені (кімната, квартира, приватний дім), а також на прилеглій до нього території (земельна ділянка, двір, сад).
Система призначена для вирішення наступних завдань:
- Контроль доступу на об'єкт автоматизації.
- Контроль мікроклімату у приміщеннях.
- Керування освітленням на об'єкті автоматизації.
- Керування водопровідною мережею на об'єкті автоматизації.
- Керування побутовою та мультимедійною електротехнікою на об'єкті автоматизації.
- Забезпечення віддаленого керування, прямого керування (у режимі реального часу), керування за розкладом об'єктом автоматизації.
- Виявлення та усунення аварійних ситуацій.
Цілями створення системи є:
- Покращення якості життя людини на об'єкті автоматизації.
- Підвищення безпеки об'єкту автоматизації.
- Зниження витрат на проживання: зниження витрат на електроенергію, зниження витрат на використання водопровідної мережі.
- Зниження тимчасових та фізичних витрат на операції, виконувані користувачем на об'єкті автоматизації.
Contents
1 Об'єкт автоматизації
Площа об'єкту автоматизації — 300 м2. Температура повітря у приміщеннях, призначених для встановлення серверу, давачів та виконавчих механізмів — від +10 до +25 °С. Температура повітря за приміщеннями, де встановлюються давачі та виконавчі механізми — від -30 до +30 °С.
Рівні забруднення, вологості, освітлення, шуму та іонізуючого випромінювання відповідають санітарно-епідеміологічним вимогам до жилих споруд та приміщень (САНПІН 2.1.2.1002-00).
На об'єкті присутнє електромагнітне випромінювання, індуковане побутовими пристроями, а також засобами електроно-обчислювальної техніки (Bluetooth, WiFi, GSM).
Система "Розумний дім. Сервер керування" являє собою програмно-апаратний модуль, який є основним керуючим центром об'єкту автоматизації. Сервер приймає та обробляє сигнали від різних давачів, формує та передає сигнали керування виконавчим пристроям, здійснює зв'язок з користувачем через мережу GSM. Керування системою користувачем здійснюється через веб-інтерфейс.
Система "Розумний дім. Сервер керування" включає наступні підсистеми:
- 1) Підсистема контролю доступу.
- 2) Підсистема контролю освітленням.
- 3) Підсистема контролю мікрокліматом.
- 4) Підсистема контролю водопровідною мережею.
- 5) Підсистема контролю побутовою та мультимедійною електротехнікою.
- 6) Підсистема обробки інформації, яка надходить з давачів.
- 7) Підсистема забезпечення інтерактивної взаємодії з користувачем через Web-інтерфейс та через мережу GSM.
- 8) Підсистема авторизації.
- 9) Підсистема формування звітів.
- 10) Підсистема конфігурації забезпечує механізми додання, витяг та редагування інформації у використаній базі даних, для роботи підсистем 1-8.
Структурну схему системи домової автоматики наведено на рисунку 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" та графічний інтерфейс розробки користувацьких інтерфейсів на основі бібліотеки побудови реактивних графічних інтерфейсів Qt.
- Модуль "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 | Головний шаблон користувацького інтерфейсу. Містить загальний інтерфейс користувача з міткою розташування вмісту сторінок «#####CONTEXT#####». |
| auth.html | Шаблон інтерфейсу авторизації з міткою розташування вмісту «#####CONTEXT#####». Створено для використання модулем протоколу 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), додання та видалення пристроїв двох типів: бінарний та десятковий.
Створювані пристрої безпосередньо розташовуються у переліку атрибутів параметру конкретно взятої підсистеми контролеру "ZigBee" модуля джерела даних ModBus (/sub_DAQ/mod_ModBus/cntr_ZegBee/). Формат запису атрибута має вигляд:
- "R:0:r:cond:Кондиціонер:bin:10:Включено:0:Виключено:(120|100)" — для бінарного давача:
- R — регістр ModBus;
- 0 — адреса регістру ModBus;
- r — тільки читання;
- cond — ідентифікатор атрибута-давача;
- Кондиціонер — назва давача;
- bin — тип давача - "Бінарний";
- 10 — перше значення;
- Включено — назва першого значення;
- 0 — друге значення;
- Виключено — назва другого значення;
- (120|100) — координати розташування ({x}|{y}) давача на схемі жилого приміщення.
- "R:3:rw:tGhost1:Температура у вітальні 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). Дані про пристрої передаються відповідно до прав доступу користувача, що увійшов.
Конфігурація давачів читається з параметру, відповідного до підсистеми, контролера "ZigBee" (/sub_DAQ/mod_ModBus/cntr_ZegBee). Значення читаються та записуються у атрибути давачів цих параметрів або через контролер відкладеного керування.
Задача контролера "ZigBee" виконується з періодом 1 секунда, у процесі чого здійснюється запит поточних значень всіх сконфігурованих давачів. Запис значень здійснюється за фактом модифікації, незалежно від задачі періодичного опитування або через контролер відкладеного керування, у випадку встановлення ненульового часу таймеру.
Зв'язок контролеру "ZigBee" здійснюється через послідовний вихідний транспорт /sub_Transport/mod_Serial/out_ZegBee.
2.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).
2.6 Звіти
У формуванні звіту визначається діапазон часу та обираються типи повідомлень. Передбачена генерація повідомлень для типів:
- "Системні повідомлення" — включає повідомлення про авторизацію та вихід користувачів на ресурсі, за посередництвом категорії повідомлень «/\/sub_Protocol\/mod_HTTP\//».
- "Події підсистем моніторингу та керування" — включають порушення та запис нових значень за давачами, за посередництвом категорії повідомлень "/(ALARM|SET)\:House\/:".
Протокол формується у вигляді таблиці (Рис.6) з часом, категорією, рівнем та повідомленням порушення, яке також записується у окремий файл звіту, надалі доступний за посиланням для окремого відкриття.
