From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Using/HouseSpirit and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська
Constr.png The translation checking and actualizing

Автоматизація жилого дому — "Розумний дім" (HouseSpirit)
Завершено: 12 06 (Червень) 2011
Засновано: 28 03 (Березень) 2011
Учасники: Роман Савоченко
Опис: Реалізація проекту автоматизації жилого дому — "Розумний дім" (HouseSpirit).
Розташування: Росія, м.Ханти-Мансійськ
Замовник: Олег Сидашов
Початково створено: у старій Wiki

HouseSpirit sch uk.png

Об'єктом автоматизації є жилий дім, оснащений обладнанням, яке підлягає автоматизації. Система призначена для автоматизації дій, виконуваних користувачем або обслуговуючим персоналом для забезпечення безпеки, комфорту, зручності проживання на об'єкті автоматизації — у жилому приміщені (кімната, квартира, приватний дім), а також на прилеглій до нього території (земельна ділянка, двір, сад).

Система призначена для вирішення наступних завдань:

  • Контроль доступу на об'єкт автоматизації.
  • Контроль мікроклімату у приміщеннях.
  • Керування освітленням на об'єкті автоматизації.
  • Керування водопровідною мережею на об'єкті автоматизації.
  • Керування побутовою та мультимедійною електротехнікою на об'єкті автоматизації.
  • Забезпечення віддаленого керування, прямого керування (у режимі реального часу), керування за розкладом об'єктом автоматизації.
  • Виявлення та усунення аварійних ситуацій.

Цілями створення системи є:

  • Покращення якості життя людини на об'єкті автоматизації.
  • Підвищення безпеки об'єкту автоматизації.
  • Зниження витрат на проживання: зниження витрат на електроенергію, зниження витрат на використання водопровідної мережі.
  • Зниження тимчасових та фізичних витрат на операції, виконувані користувачем на об'єкті автоматизації.

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.

Рис.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-сайту, який виконує безпосередній прийом, первинну обробку та формування остаточної відповіді, а саме:
  • Обслуговування запитів до сторінок-шаблонів:
    • читання файлу обраної сторінки-шаблону, якщо обрання мало місце;
    • читання та розбір файлу головного шаблону інтерфейсу (main.html);
    • розташування поточного часу сервера у атрибуті "value" елементу дерева головного шаблону з ідентифікатором "time_vl";
    • розташування початкового значення лічильника активного сеансу у атрибут "value", елементу дерева головного шаблона з ідентифікатором "ses_vl";
    • перевірка загального доступу автентифікованого користувача до тих або інших частин інтерфейсу та приховання елементів до яких немає доступу на перегляд;
    • обробка обраного пункту меню сторінки:
      • підсвічування елементу меню активної сторінки;
      • пошук та виклик скрипту динаміки (/sub_DAQ/mod_JavaLikeCalc/lib_web/*) однойменно, або з аргументу "script URL", обраної сторінки.
    • читання файлу сторінки привітання (welcome.html), у випадку відсутності обрання сторінки з меню;
    • встановлення значень поточної сторінки та користувача у рядку статусу;
    • розташування контексту сторінки у головний шаблон інтерфейсу.
  • Обслуговування запитів до файлів ресурсів та звітів:
    • Обробка розширень файлів ресурсу та формування атрибуту типу (Content-Type), передаваного контенту.
  • Генерація відповідей з помилкою у випадку відсутності сторінок-шаблонів або файлів ресурсів.
Бібліотека скриптів шаблонів-сторінок та системних процесів (/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:Включено: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). Дані про пристрої передаються відповідно до прав доступу користувача, що увійшов.

Рис.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 Звіти

У формуванні звіту визначається діапазон часу та обираються типи повідомлень. Передбачена генерація повідомлень для типів:

  • "Системні повідомлення" — включає повідомлення про авторизацію та вихід користувачів на ресурсі, за посередництвом категорії повідомлень «/\/sub_Protocol\/mod_HTTP\//».
  • "Події підсистем моніторингу та керування" — включають порушення та запис нових значень за давачами, за посередництвом категорії повідомлень "/(ALARM|SET)\:House\/:".

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

Рис.6. Звіти.

3 Посилання