Удосконалення програмного забезпечення технічного засобу інтернету речей (IoT)

Авраменко, Віталій Миколайович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9096
Title:	Удосконалення програмного забезпечення технічного засобу інтернету речей (IoT)
Authors:	Олексюк, Вадим Володимирович Авраменко, Віталій Миколайович
Keywords:	Розумний будинок;JSON Web Tokens (JWT);алгоритми управління;моделі поширення програмного забезпечення;Redux;інформаційні технології управління;хмарні обчислення;WebSocket та Server-Sent Events;системи Software as a Service (SaaS);Інтернет речей (IoT)
Issue Date:	2024
Abstract:	Авраменко В.М. Кваліфікаційна робота магістра на тему «Удосконалення програмного забезпечення технічного засобу інтернету речей (IoT)». Напрям підготовки 121 «Інженерія програмного забезпечення». Черкаський державний технологічний університет, м. Черкаси, 2024 р. Дослідження присвячене розробці та впровадженню інформаційних технологій для управління системами "розумного" будинку, зокрема автоматизації керування побутовими пристроями та технікою. На фоні існуючих програмних продуктів, які переважно орієнтовані на взаємодію через смартфони, висвітлено важливість розробки систем, що використовують алгоритми для автоматизованого прийняття управлінських рішень. Основна ідея полягає в покращенні ефективності та комфорту користувачів, забезпечуючи автоматизований контроль за побутовою технікою без активного втручання користувачів. Детально розглянуті різні аспекти розумного будинку, зокрема алгоритми управління, моделі обробки великих обсягів даних, та архітектурний шаблон Redux для оптимізації обробки даних у реальному часі. Досліджено можливості поширення програмного забезпечення, впроваджуючи моделі Software as a Service (SaaS), що дозволяє підвищити ефективність розумних систем. Особливий акцент зроблено на науковій новизні дослідження, включаючи подальший розвиток методів управління "розумним" будинком, використання архітектурного шаблону Redux та впровадження моделей поширення програмного забезпечення на основі SaaS. Отримані результати виявляють перспективи новаторських підходів до управління системами "розумного" будинку. На практичному рівні вивчено та розроблено програмний засіб для інформаційної технології управління системою "розумного" будинку. Реалізовані алгоритми та інтерфейси орієнтовані на оптимізацію використання ресурсів та забезпечення високого рівня безпеки та зручності для кінцевих користувачів. Загальна мета дослідження та його результати визначають важливість подальшого розвитку систем "розумного" будинку, зокрема з використанням хмарних обчислень для забезпечення надійності, масштабованості та економії витрат при експлуатації розробленої системи. Актуальність роботи обумовлена потребою у вдосконаленні систем управління для забезпечення сучасного та ефективного життя в розумних будинках.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/9096
Appears in Collections:	121 Інженерія програмного забезпечення (Інженерія програмного забезпечення)
Files in This Item:
File	Description	Size	Format
Віталій Авраменко.pdf Restricted Access		2.52 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
ЧДТУ.232201.001 ПЗ 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет інформаційних технологій і систем 
Кафедра програмного забезпечення автоматизованих систем 
 
 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
«магістра» 
освітній рівень 
  
на тему:  Удосконалення програмного забезпечення технічного засобу 
інтернету речей (IoT) 
 
 
 
 
 
 
Виконав: студент 2 курсу, групи МПЗ-2204 
Напряму підготовки  
121 «Інженерія програмного забезпечення»  
(шифр і назва напряму підготовки) 
 
 
Студент Авраменко В.М. 
 (прізвище та ініціали) 
Керівник Олексюк В.В. 
 (прізвище та ініціали) 
Рецензент  
 (прізвище та ініціали) 
 
 
Черкаси 2023 
ЧДТУ.232201.001 ПЗ 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ................................................................... 4 
ВСТУП ......................................................................................................................... 5 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ ............................Помилка! Закладку не визначено. 
1.1 Концепція «Розумного будинку» .................................................................... 8 
1.2 Базові елементи Smart Home System ............................................................. 11 
1.3 Аналіз побудови систем «розумний будинок» ............................................ 16 
1.4 Рівнева архітектура інтернету речей ............................................................. 31 
Висновки до розділу 1………...…………………………………………………36 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
 ................................................................................Помилка! Закладку не визначено. 
2.1 Теоритичні дослідження ................................................................................. 37 
2.2 Ефективність опрацювання даних у системах «розумного» будинку ....... 44 
2.3 Експериментальні дослідження ..................................................................... 51 
Висновки до розділу 2………………….…..……………………………………58 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У 
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 
ІНФОРМАЦІЙНИХ СИСТЕМ ........................Помилка! Закладку не визначено. 
3.1 Моделювання предметної області ................................................................. 60 
 3.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області……………………………………………………….60 
 3.1.2 Елементи моделювання предметної області…………………………61 
 3.1.3 Робоча область моделювання…………………………………………63 
3.2 Формування та аналіз вимог .......................................................................... 63 
 3.2.1 Формування вимог до програмного забезпечення. Первині і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні  
вимоги……………………………………………………………………………….63 
 
 
ЧДТУ.232201.001 ПЗ 
 
 3.2.2 Формування вимог за допомогою діаграми прецедентів…………...67 
 3.2.3 Проектування логічної структури програмного комплексу………..68 
 3.2.3.1 Діаграми класів……………………………………………………...70 
3.2.3.2 Діаграми пакетів…………………………………………………….71 
3.2.4 Архітектурне проектування………………………………………………71 
 3.2.4.1 Діаграма компонентів………………………………………………72 
 3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання…………………………………………………………………………74  
3.2.5 Моделювання поведінки системи .............................................................. 77 
 3.2.5.1 Діаграма діяльності ………………………………………………....77 
 3.2.5.2 Діаграма послідовності ………………………………………….….78 
 3.2.5.3 Діаграма комунікації…………………………………………….…..79 
 3.2.5.4 Діаграма скінченого автомату………………………………….…...80 
Висновки до розділу 3………...…………………………………………...…….81 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ .................................................................................................... 80 
4.1.Розробка програмного комплексу ................................................................. 80 
 4.1.1 Обґрунтування вибору засобів реалізації ...…………………………80 
 4.1.2 Опис структурної (функціональної) схеми…………………………..84 
 4.1.3 Опис логічної схеми системи…………………………………………85 
 4.1.4 Розробка бази даних……………………………  …………………….86  
 4.1.5 Розробка інтерфейсу користувача……………………………………87 
 4.1.6 Опис розробки програмних компонентів……………………….……87 
4.2 Тестування системи ........................................................................................ 88 
 4.2.1 Модульне тестування………………………………………………….90 
4.2.2 Інтеграційне тестування……………………………………………….93 
 4.2.3 Системне тестування…………………………………………………..95 
 4.2.4 Приймальне тестування……………………………………………….96 
4.3 Приклади впровадженого програмного комплексу……………….……....98 
ЧДТУ.232201.001 ПЗ 
Висновки до розділу 4……..…………………………………………………102 
ВИСНОВОК ........................................................................................................... 104 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ .......................................................... 106 
ДОДАТКИ…………………………………………………………………….......112 
ЧДТУ.232201.001 ПЗ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ 
БД  – база даних 
ПЗ  – програмне забезпечення 
UI   – user interface (інтерфейс користувача) 
API – application programming interface (прикладний програмний 
інтерфейс) 
IoT   – internet of things (інтернет речей) 
AI   – artificial intelligence (штучний інтелект) 
SaaS  – software as а service (програма як послуга) 
DNS   – domain name system (система доменних імен) 
МАС  – мультиагентні системи 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
ЧДТУ.232201.001 ПЗ 
ВСТУП 
Актуальність теми. Серед наявних програмних продуктів для управління 
домашніми пристроями переважають розробки, спрямовані на керування 
пристроями через смартфони користувачів, при цьому практично відсутні 
рішення для автоматизації управління технікою. Це є перспективним напрямком 
для розробки та впровадження систем, які використовують алгоритми для 
автоматизованого прийняття управлінських рішень. Отже, існує потреба в 
інструментах, що реалізують механізм автоматизованого управління системами 
"розумного" будинку, забезпечуючи комфорт мешканців та підвищення 
енергоефективності, при цьому не вимагаючи активного втручання користувачів. 
Актуальність роботи полягає в розвитку систем "розумного" будинку з 
використанням різноманітних обчислень, що дає можливість широкого 
масштабування та зменшення витрат на впровадження розроблених систем 
управління. У роботі проводиться дослідження методів та засобів 
автоматизованого управління побутовими пристроями будинку за допомогою 
різних сервісів обчислень. Також вивчається застосування алгоритмів для 
автоматизованого прийняття рішень системою. Робота визначає та аналізує 
методи пошуку оптимальних параметрів для вирішення завдань у контексті 
функціонування систем "розумного" будинку, а також використання хмарних 
обчислень для забезпечення надійності, масштабованості та економії витрат при 
експлуатації розробленої системи "розумного" будинку. 
Мета і задачі дослідження. Метою даного дослідження є розвиток методів 
та інструментів для створення інформаційних технологій управління домашніми 
пристроями з використанням різних алгоритмів керування.  
Для досягнення цієї мети поставлено ряд завдань: 
– провести аналіз існуючих методів, моделей та засобів управління 
"розумним" будинком та алгоритмів управління. 
– дослідити методи обробки великих обсягів даних для систем 
"розумного" будинку, заснований на архітектурному шаблоні Redux. 
5 
ЧДТУ.232201.001 ПЗ 
– впровадити модель поширення програмного забезпечення для систем 
"розумного" будинку, що ґрунтується на використанні моделі SaaS. 
– розробити програмний засіб для інформаційної технології управління 
системою "розумного" будинку. 
Об’єкт дослідження – процес управління системою "розумного" будинку, 
використовуючи технології та алгоритми керування.  
Предмет дослідження – методи моделювання та засоби управління 
системою "розумного" будинку, які використовують технології хмарних 
обчислень. 
Методи дослідження. У дослідженні застосовано методи синтезу та 
аналізу для вирішення поставлених задач. Метод синтезу та аналізу 
використовується для розробки архітектури та програмної реалізації розподіленої 
системи "розумного" будинку з використанням алгоритму керування 
компонентами будинку. 
Наукова новизна отриманих результатів. В роботі отримано наступну 
наукову новизну: 
– отримало подальший розвиток існуючі методи управління "розумним" 
будинком, включаючи різноманітні алгоритми та моделі. Досліджено не 
тільки традиційні, але й передові підходи, враховуючи виклики та 
потреби сучасного життя. Здійснено критичний огляд підходів, що 
відкриває можливості для розробки нових, більш ефективних стратегій 
управління "розумним" будинком. 
– удосконалено метод поєднання архітектурного шаблону Redux із 
методами обробки великих обсягів даних для систем "розумного" 
будинку шляхом впливу Redux на швидкість та ефективність обробки 
даних у реальному часі.  
– вперше впроваджено моделі поширення програмного забезпечення для 
систем "розумного" будинку на основі моделі Software as a Service за 
рахунок стратегії інтеграції, що підвищують ефективність розумних 
систем. 
6 
ЧДТУ.232201.001 ПЗ 
– удосконалено комплексний програмний засіб, що базується на 
передових інформаційних технологіях для управління системою 
"розумного" будинку. Розроблені алгоритми та інтерфейси, спрямовані 
на оптимізацію використання ресурсів, забезпечують високий рівень 
безпеки та зручності для користувачів. 
Практичне значення отриманих результатів дослідження виявляється в 
тому, що розроблений підхід до використання алгоритму керування у середовищі 
хмарних обчислень є універсальним і може служити для підтримки процесів 
автоматизованого прийняття рішень у системах "розумного" будинку без 
обмежень щодо конкретних завдань, таких як безпека, енергоефективність та 
інші. 
Публікації. Ефективні алгоритми збору, обробки та передачі даних у 
системах IoТ / В.М. Авраменко // «Сучасні методи, інформаційне, програмне та 
технічне забезпечення систем керування організаційно-технічними та 
технологічними комплексами»: Тези доповідей десятої міжнародної науково-
технічної internet-конференції: (24 листопада 2023 р., Київ), 2023. – С. 171. 
7 
ЧДТУ.232201.001 ПЗ 
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ 
ПОСТАВЛЕНИХ ЗАВДАНЬ 
1.1 Концепція «Розумного будинку» 
Початок розвитку концепції розумного будинку можна визначити середину 
XX століття, що збігається з початком комп'ютерної епохи, яка стала основою 
для розробки системи. У той час компоненти були невеликі, всі модулі були 
масивними та працювали за допомогою перфокарт, але вони успішно виконували 
свої завдання. 
В 60-х роках минулого століття Джеймс Сазерленд успішно програмував 
комп'ютер для включення пристроїв за розкладом, а також взаємодіяв з 
датчиками та системами сигналізації. 
У 1978 році шотландська фірма Pico Electronics впровадила стандарт 
передачі інформації для домашньої автоматизації, що використовувався шиною 
для підключення побутових приладів до автоматизованого керування через 
розетки. Після встановлення цього стандарту розпочалася ера експериментів. 
Термінологія "розумний будинок" офіційно з'явилася в 1984 році від 
Американської асоціації житлово-будівельних компаній. Пізніше до розвитку 
системи приєдналася асоціація електронної промисловості, що допомогла 
реалізувати новий стандарт - CEBus. 
Широке введення поняття "розумний будинок" серед громадськості 
відбулося завдяки фільму від компанії Disney, в якому показано 
комп’ютеризований будинок. З початку 2000-х років почали з'являтися масові 
виробники, і компанія Apple внесла великий вклад, випустивши перший iPhone. 
До 2012 року в Америці було встановлено понад 1,5 мільйона систем домашнього 
управління. 
Останні роки принесли спостереження за зростанням взаємодії мільярдів 
пристроїв та інформаційних систем. Це призвело до покращення повсякденного 
життя людей і підвищення ефективності комерційних компаній, які можуть 
мінімізувати експлуатаційні витрати та оптимізувати використання активів. 
8 
ЧДТУ.232201.001 ПЗ 
Застосування Інтернету речей (IoT) паралельно з алгоритмами штучного 
інтелекту (AI) стає актуальним, оскільки розвиток "розумних" систем 
переноситься від централізованих хмарних обчислень до децентралізованого 
підходу. 
Згідно з Кривою Курцвейла [1], очікується експоненційний ріст 
використання машинного інтелекту, з'явлення передових обчислювальних 
платформ для роботи AI на рівні людського мозку. Це визначається збільшенням 
обсягу даних від пристроїв IoT, покращенням алгоритмів штучного інтелекту, 
компактними форм-факторами пристроїв IoT та ефективнішим споживанням 
енергії. 
Ринок IoT очікує стабільний ріст завдяки зв'язаності мільярдів пристроїв та 
інформаційних систем, що основується на поширенні доступних датчиків для 
перетворення фізичних подій в цифрові дані. Використання пристроїв IoT, 
спрямованих на заощадження пального та оптимізацію енергоспоживання, 
допомагає підприємствам економити кошти та скорочувати терміни окупності. 
Очікується, що витрати на IoT будуть щорічно зростати [2]. 
Прогнозується, що пристрої IoT зіберуть 90 зеттабайт даних до 2025 року 
[3], які подаються в централізовані платформи для обробки, зберігання, аналізу та 
візуалізації. Централізована архітектура дозволяє великомасштабні обчислення та 
ефективне зберігання, але при цьому має недоліки у вигляді затримок у обміні 
даними, вразливості до екологічних катастроф та вартості масштабування. 
Відсутність універсальності та вразливість до хакерських атак також роблять 
централізовані архітектури менш привабливими, стимулюючи перехід до 
розподіленої або децентралізованої архітектури з фокусом на хмарні обчислення 
та можливості штучного інтелекту [3]. 
Терміни "розумний будинок" та "автоматизація побутових процесів" є 
многозначними та використовуються для опису різноманітних рішень з 
контролю, моніторингу та автоматизації в домашньому середовищі. Згідно з 
визначенням Берга Інсайта, щоб бути визнаним "розумним", інформаційна 
система повинна мати додаток для смартфонів або веб-портал як користувацький 
9 
ЧДТУ.232201.001 ПЗ 
інтерфейс. Таким чином, пристрої, які використовують лише перемикачі, 
таймери, датчики та пульти дистанційного керування, не вважаються 
"розумними". 
Системи "розумного" будинку можна класифікувати в шість основних 
категорій: безпека та контроль доступу, управління електроенергією та 
температурним режимом, аудіовізуальні та розважальні системи, управління 
освітленням та жалюзями/шторами, системи охорони здоров'я, побутова техніка 
та роботизація. 
Ринок "розумних" будинків в Північній Америці переживає значний ріст. 
Кількість встановлених систем "розумного" будинку зросла на 51,1%, до 82,7 
мільйона. Приблизно 8,3 мільйона з них є багатофункціональними, тоді як 74,4 
мільйона - локальними рішеннями для конкретних функцій. З огляду на те, що 
деякі будинки можуть використовувати декілька "розумних" систем, приблизна 
кількість "розумних" будинків на кінець 2007 року складала 22,3 мільйона, що 
становить 15,9% всіх домашніх господарств Північної Америки. Очікується, що 
кількість будинків з системами "розумного" будинку зростатиме з річним темпом 
23,1%, до приблизно 63,0 мільйона до 2022 року. 
Локальні рішення становлять 61% прибутку ринку "розумних" пристроїв в 
Північній Америці та Європі. Серед найбільш успішних продуктів на сьогодні 
варто відзначити "розумні" термостати, лампи, розетки, мережеві камери, 
багатокімнатні аудіосистеми та голосово керовані "розумні" колонки. Amazon та 
Google мають понад 90% частку ринку голосових помічників. Такий попит на 
"розумні" системи будинку може бути пов'язаний із популярністю голосових 
помічників. Загалом, високий попит на системи "розумного" будинку 
визначається швидким розвитком технологій та зростаючим інтересом 
споживачів до комфорту та економії фінансових ресурсів. 
Архітектура розумного будинку вказує на те, що новозбудовані будинки 
часто використовують інфраструктуру розумного будинку, тоді як в старих 
будинках можна впроваджувати інтелектуальні технології. Протоколи зв'язку 
Zigbee і Z-Wave є найбільш популярними у сучасних системах, забезпечуючи 
10 
ЧДТУ.232201.001 ПЗ 
підключення пристроїв до мережі розумного будинку. Концентратор розумного 
будинку, такий як Amazon Echo чи Google Home, використовується як центральна 
точка управління, об'єднуючи всі різні додатки в одному інтерфейсі для 
віддаленого керування. 
Системи розумного будинку можуть бути створені від самого початку, 
наприклад, за допомогою Raspberry Pi, чи придбані у вигляді готового набору для 
розумного будинку. Вони використовують машинне навчання і штучний інтелект 
для персоналізації та адаптації до уподобань користувачів, наприклад, за 
допомогою систем голосового управління. 
Таким чином, розумний будинок не просто набір розрізнених пристроїв, а 
система, яка працює в єдність для створення віддалено керованої мережі 
(рисунок 1.1). 
 
 
Рисунок 1.1 – Архітектура Smart Building 
 
1.2 Базові елементи Smart Home System 
Існує низка різноманітних компонентів у системі розумного будинку, але їх 
можна узагальнити до кількох основних елементів, які визначають архітектуру 
стандартної системи розумного будинку, як показано на рисунку 1.2. Перш за 
11 
ЧДТУ.232201.001 ПЗ 
все, це датчики, які вимірюють стан оточуючого середовища та актори, які 
зберігають або змінюють цей стан [12]. 
Всі ці датчики та об'єкти з'єднані з центральною базовою станцією, яка 
збирає та контролює весь зібраний інформаційний потік. Крім того, база з'єднана 
з клієнтом віддаленого управління, зазвичай через веб-браузер або мобільний 
додаток. Це підключення може бути налаштоване безпосередньо, наприклад, в 
одній локальній мережі або, як у більшості сучасних систем розумного будинку, 
через хмарний інтерфейс, що забезпечується постачальником для забезпечення 
віддаленого доступу до системи [30]. 
 
 
Рисунок 1.2 – Базові елементи Smart Home System 
12 
ЧДТУ.232201.001 ПЗ 
Управління архітектурою "Розумного будинку" 
Можливість управління розумним будинком не є чимось новим і успішно 
реалізовано великими комерційними системами. Проте для більшості людей 
встановлення таких систем вважається дорогою, тому стає все популярнішим 
власноруч розробляти свою систему або адаптувати відкриті системи 
автоматизації під власні потреби. При цьому здійснення віддаленого управління 
розумним будинком вимагає вирішення декількох проблем, таких як можливість 
звертатися до системи ззовні, що потребує статичної IP-адреси. Зазвичай 
інтернет-провайдери пропонують динамічну адресу, тоді як отримання статичної 
може бути проблематичним, і для цього часто використовуються сервіси, такі як 
DynDNS або NO-IP [13]. Як альтернативу, рекомендується використовувати 
хмарні сервіси, які стають все доступнішими, і при невеликих запитах можна 
скористатися їхніми ресурсами безкоштовно. Крім того, цей метод має кілька 
переваг порівняно з використанням статичної або динамічної адреси [32]. Для 
початку слід визначитися з архітектурою системи. Існують два основних типи 
архітектури систем розумного будинку: децентралізована та централізована. 
Децентралізована архітектура ґрунтується на тому, що всі вузли в мережі 
рівноправні. В такому розумному будинку кожна підсистема наділена рівними 
правами по відношенню до інших, і вся логіка роботи підпорядкована простим 
сценаріям, відповідно до яких керуючі сигнали передаються безпосередньо від 
однієї підсистеми до іншої при настанні певних умов. 
Централізована архітектура передбачає наявність центрального контролера, 
який управляє підключеними до нього модулями. Також існує суміщений підхід, 
при якому центральний контролер управляє декількома підсистемами, які при 
виникненні неполадок з сервером продовжують виконувати мінімально 
закладений в них функціонал (рисунок 1.3). 
 
13 
ЧДТУ.232201.001 ПЗ 
 
Рисунок. 1.3 – Архітектура системи віддаленого управління 
 
У системі "Розумного будинку" потрібен центральний сервер управління, 
оскільки з його допомогою здійснити клієнт-серверну взаємодію між мобільним 
додатком та розумним будинком, а також забезпечити зв'язок з хмарним 
сервером. Система віддаленого управління включає такі основні компоненти: 
мобільний додаток, хмарний сервер, домашній сервер та мікроконтролер для 
управління датчиками і сенсорами. 
Мобільний додаток 
Мобільний додаток є обов'язковим для віддаленого управління розумним 
будинком. Хоча можна скористатися звичайним браузером, додаток виявляється 
зручнішим та має інші переваги, такі як push-повідомлення. 
Push – це технологія поширення інформації від сервера до клієнта, а Push 
повідомлення – це невеликі спливаючі вікна на екрані пристрою. За допомогою 
мобільного додатка передаються команди на хмарний сервер та отримуються 
звідти дані про стан датчиків. 
Додаток для iOS розробляється в середовищі Xcode з використанням мови 
програмування Swift. Для отримання та відправки даних використовується 
фреймворк Alamofire, а для локального зберігання даних - фреймворк CoreData. 
Додаток має два режими підключення до сервера: безпосередньо з локальної 
14 
ЧДТУ.232201.001 ПЗ 
мережі і через хмарний сервер. При запуску перевіряється наявність сервера в 
локальній мережі і, якщо його немає, відбувається підключення до хмарного 
сервера. Для обміну даними і командами з сервером використовується REST API, 
а дані передаються у форматі JSON [13]. 
Хмарний сервер 
Хмарна модель надання сервісів швидко розвивається, і більшість функцій 
по обробці, управлінню та зберіганню інформації вже доступні у формі хмарних 
сервісів. Один із найкращих PaaS - Firebase від Google. Firebase - це база даних, 
що змінюється в реальному часі та зберігає дані в JSON. Зміни в базі даних 
миттєво синхронізуються між усіма пристроями, які використовують одну базу 
даних. Хмарний сервер приймає команди з мобільного пристрою і передає їх на 
домашній сервер. Якщо домашній сервер повідомляє про зміну стану пристрою в 
будинку, хмарний сервер відправляє push-повідомлення на мобільний пристрій 
[13]. 
Щоб отримувати push-повідомлення, додаток реєструється, iOS отримує 
токен від сервера Apple Push Notification Service (APNS), і цей токен 
відправляється на хмарний сервер. Коли відбувається подія, хмарний сервер 
відправляє push-повідомлення на девайс користувача через APNS, і коли девайс 
отримує повідомлення, виводиться на екран та відтворює звуковий сигнал. 
Домашній сервер 
Домашній сервер служить для отримання команд від хмарного сервера та їх 
подальшої передачі контролерам, а також для передачі назад даних з датчиків, що 
надходять на контролер. Також забезпечує управління системою по локальній 
мережі з мобільних пристроїв по Wi-Fi. В якості домашнього сервера можна 
використовувати звичайний персональний комп'ютер. Розробляється з 
використанням мови Python і бібліотеки Django, а для зберігання даних 
використовується база даних SQLite. Алгоритм роботи сервера описується на 
прикладі запиту з мобільного додатку для отримання даних з датчиків у певній 
кімнаті [13]. 
1 Отримання запиту. 
15 
ЧДТУ.232201.001 ПЗ 
2 Визначення потрібного уявлення за шаблоном. 
3 Подання запиту у моделі даних кімнати. 
4 Відправлення запиту контролеру на отримання даних з датчиків. 
5 Отримання відповіді від контролера та формування відповіді для 
додатка. 
6 Відправлення відповіді з додатком у форматі JSON. 
Мікроконтролер 
Контролер Arduino став визнаною платформою для швидкого створення 
електронних пристроїв як для початківців, так і для фахівців. Його популярність 
по всьому світу обумовлена простотою мови програмування, відкритою 
архітектурою і доступним вихідним кодом. Програмування пристрою 
здійснюється через USB, не вимагаючи використання програматорів [13]. 
Мікроконтролер на платі програмується за допомогою мови Arduino (базованої 
на Wiring) та середовища розробки Arduino (базованого на Processing). Контролер 
управляє підключеними датчиками, отримує команди від домашнього сервера і 
відсилає інформацію про зміни станів датчиків [13]. 
Алгоритм роботи контролера: 
– сервер висилає запит контролеру. 
– контролер приймає запит. 
– обробка запиту, отримання параметрів із запиту. 
– отримання даних з датчиків або відправлення даних на датчик. 
– формування відповіді сервера. 
– відсилання відповіді. 
1.3 Аналіз побудови систем «розумний будинок»  
Кількість пристроїв, які полегшують повсякденне життя людини, стабільно 
збільшується. Різноманітні комунікаційні засоби та гаджети потребують все 
більше уваги та, відповідно, часу на налаштування. Концепція домашньої 
автоматизації полягає в об'єднанні всіх пристроїв під централізоване управління, 
що реалізовано за допомогою системи "Розумний будинок". 
16 
ЧДТУ.232201.001 ПЗ 
Сучасний світ технологій організований таким чином, що ідеальних рішень 
не існує. Основне завдання для тих, хто бажає зробити свій будинок розумним, 
полягає в тому, щоб визначити, які функції та можливості є необхідними, і як це 
реалізується у різних виробників. 
Samsung SmartThings, зокрема, представляє собою екосистему додатків 
для Інтернету речей. 
Проект SmartThings вирушив у світ у 2012 році як частина кампанії на 
Kickstarter. Основна ідея полягала в розробці рішення для створення розумного 
домашнього середовища за допомогою концентратора, що був підключений до 
різноманітних "речей", таких як датчики температури, вологості та диму. 
Початково проект був доповнений мобільним додатком, який забезпечував 
зв'язок з віддаленим концентратором [17]. 
В 2014 році Samsung Electronics придбала SmartThings, що призвело до 
суттєвих змін у його архітектурі, зробивши її спрямованою на хмарову 
платформу [17]. 
Як показано на рисунку 1.4, пристрої можна підключати до хмарної 
серверної частини за допомогою трьох різних шляхів, навіть без прямого 
з'єднання з концентратором [17]. 
 
 
Рисунок 1.4 – Архітектура SmartThings 
17 
ЧДТУ.232201.001 ПЗ 
Інший тип з'єднання - з'єднання з хмарою, яке дозволяє встановлювати 
непрямий канал зв'язку між (хмарним) стороннім пристроєм та хмарою 
SmartThings. Проте рекомендується наявність концентратора, який діє як шлюз 
між пристроями і хмарою. Деякі операції можуть виконуватися локально без 
необхідності звертатися до серверної частини [17]. 
У випадку SmartThings комунікація відбувається через концентратор, 
використовуючи протоколи бездротового зв'язку ZigBee або Z-Wave. Об'єкти в 
додатку SmartThings організовані і груповані відповідно до приміщення, де вони 
знаходяться. Таким чином, концепція приміщення виявляється ключовою для 
користувачів SmartThings [17]. 
SmartThings включає концепцію автоматизації, яка дає користувачам 
можливість взаємодіяти з екосистемою без ручного втручання. Щодо 
автоматизації, існують дві стратегії: одна ґрунтується на WebHook, а інша - на 
функціях AWS Lambda. Наприклад, можна встановити стратегію автоматизації 
для регулювання інтенсивності освітлення в конкретному приміщенні залежно 
від зміни погоди. Це хмарне рішення також забезпечує шифрований зв'язок між 
всіма підключеними компонентами через протокол SSL/TLS [17]. 
Запропонована архітектура SmartThings орієнтована на домашнє 
середовище або концепцію інтелектуальної будівлі. Її особливості дозволяють 
застосовувати її в більш широкому контексті, наприклад, за допомогою хмарних 
з'єднань можна було б підключити сенсорну мережу [17]. 
Докладніше про компоненти архітектури Samsung SmartThings [14]. 
Пристрої SmartThings 
Pристрої SmartThings можуть включати не лише пристрої із набору 
SmartThings, але й різноманітні сторонні пристрої від партнерів. Якщо пристрій 
не входить до списку офіційно підтримуваних, можна знайти для нього Обробник 
пристроїв, який може бути наданий розробниками у спільноті, або розробити 
власний [14]. 
18 
ЧДТУ.232201.001 ПЗ 
Методи підключення 
Підключення пристроїв до платформи можливе трьома способами [14]: 
– Hub-connected: через хаб-концентратор для пристроїв, які не мають 
власного виходу в Інтернет і взаємодіють через традиційні бездротові 
мережі, такі як ZigBee. 
– Directly-connected: безпосереднє підключення до Інтернету, обходячи 
хаб. Деякі пристрої, такі як відеокамера, лампочка та розумна розетка, 
працюють без хаба через Wi-Fi. 
– Cloud-connected: підключення через сторонню хмару для пристроїв, які 
вже мають власну хмарну екосистему. 
Для підключення різних пристроїв у приміщенні зазвичай 
використовується спеціальний сервер "Розумного будинку", який підтримує різні 
протоколи. Цей сервер, відомий як хаб, концентратор або шлюз, є необхідним 
елементом [14]. 
Додаток SmartThings можна встановити на основні мобільні ОС і 
використовувати для [14]: 
– додавання нових пристроїв у систему; 
– контролю вже доданих пристроїв; 
– створення правил автоматизації; 
– отримання повідомлень через push і SMS. 
Абстракції 
У SmartThings, як і в багатьох інших платформах "Розумного будинку", 
використовуються такі абстракції: кімнати, сцени, сценарії [14]. 
1 Приміщення групуються в кімнати (Rooms), де користувачі можуть легко 
призначити та іменувати свої гаджети, такі як "Кухня", "Ванна", 
"Вітальня" [14]. 
19 
ЧДТУ.232201.001 ПЗ 
2 Сцени (Scenes) визначають різні ситуації, такі як "сон", "відпочинок", 
"робота", "перегляд фільму", кожна з яких має свій набір станів 
пристроїв [14]. 
Сцени та кімнати у додатку 
Також присутні сценарії (Routines), які визначають правила автоматизації 
за принципом "якщо - то". У програмі за замовчуванням чотири сценарії: "Я 
повернувся", "На добраніч", "Пока", "Доброго ранку". Можна налаштувати 
активацію сценарію в залежності від умов, таких як ранок, рух або відкриття 
дверей [14]. Наприклад, при вході додому можна автоматично заблокувати 
мережевий трафік на камері відеоспостереження для захисту особистої 
інформації. Інший приклад – автоматичне відключення планшета від мережі о 11 
годині вечора для забезпечення здорового сну [14]. Крім того, програма 
SmartThings на телефоні має корисну можливість – автоматичне запам'ятовування 
типових дій, надаючи рекомендації щодо налаштування сцен . 
Для введення нових пристроїв у систему існує система плагінів. 
Розробники можуть створювати плагіни для своїх пристроїв, що надають 
інтерфейс користувача всередині програми SmartThings та логіку роботи 
пристрою.  
Плагіни, в суті, є веб-додатками і можуть підписуватися на події чи 
повідомлення від пристрою, взаємодіяти з ним та моніторити статус з'єднання. 
Особливості роботи SmartThings 
Вся система SmartThings ґрунтується на головному контролері – Hub. Цей 
пристрій підтримує бездротову мережу, необхідну для взаємодії з усіма 
"розумними" пристроями в будинку. Hub виконує функції роутера, проте 
стандартний Wi-Fi роутер тут не вдасться. Для повноцінної роботи системи 
необхідні обидва пристрої, які з'єднуються за допомогою Ethernet [16]. 
Hub має потужний процесор, що дозволяє підтримувати режим 
відеоспостереження, а його акумулятор забезпечує до 10 годин автономної 
20 
ЧДТУ.232201.001 ПЗ 
роботи. Цього достатньо для забезпечення безперебійної роботи системи в 
умовах відключення електроенергії.  
Hub використовує інтерфейс Zigbee або Z-wave, а також може підтримувати 
локальне з'єднання по IP [16]. Щодо безпеки, прилади, які мають мітку "Працюю 
зі SmartThings", проходять сертифікацію і відповідають вимогам безпеки. 
Система гарантує безпеку, якщо підключені сертифіковані пристрої [16]. 
Переваги та недоліки системи Samsung SmartThings 
Переваги: 
– гнучкий мобільний додаток; 
– підтримка Amazon Alexa, Google Assistant; 
– сумісність з сотнями "розумних" пристроїв. 
– активне співтовариство розробників. 
– гнучка і централізована система управління. 
– є батарея резервного живлення. 
– підтримка протоколів Zigbee та Z-Wave. 
Недоліки: 
– обмежені можливості підключення по Bluetooth. 
Apple HomeKit 
HomeKit – це програмна платформа від Apple, яка дозволяє користувачам 
iOS, macOS, watchOS і tvOS керувати розумними пристроями вдома через 
додаток Home або голосового помічника Siri [17]. HomeKit базується на 
незалежних пристроях, з'єднаних між собою через Wi-Fi. Багато з цих пристроїв є 
автономними і можуть працювати навіть якщо ви не плануєте придбувати більше 
"розумних" пристроїв. Однак деякі працюють за протоколом Bluetooth і 
вимагають головного пристрою, що виконує функції шлюзу. Зазвичай це кнопки і 
датчики (температури, відкриття, руху і т. д.). Вони можуть підключатися 
безпосередньо до iPhone в зоні видимості, але оптимально використовувати 
пристрій удома в якості шлюзу, такий як Apple TV, колонка HomePod або 
21 
ЧДТУ.232201.001 ПЗ 
планшет iPad. Проте, дія Bluetooth обмежена, і великий будинок може вимагати 
кількох "хабів" [15]. 
 
 
Рисунок 1.5 – Архітектура системи на базі Homebridge 
 
Apple не виробляє жодного пристрою для HomeKit, крім "хабів". Усі інші 
пристрої створюють партнери і сертифіковані за стандартом MFi. Це може бути 
як плюс, так і мінус. З одного боку, сувора сертифікація гарантує високий рівень 
безпеки і стійкість до вторгнень. З іншого боку, через це кількість партнерів для 
HomeKit у Apple обмежена, і ціни на пристрої вищі. Загалом, система підтримує 
приблизно 450 офіційно сертифікованих пристроїв [15]. 
ПЗ Homebridge дозволяє додавати в HomeKit пристрої не лише з інших 
систем "розумного" будинку. Це, звісно, не ідеальний варіант з точки зору 
цілісності і безпеки, але це ефективний компроміс для тих, хто не хоче 
обмежувати себе в різноманітності HomeKit і, в той же час, бажає отримати 
зручне управління з iPhone або Apple Watch (рисунок 1.5) [15]. 
Керування компонентами системи можливе лише за допомогою 
електроніки від Apple. З іншого боку, навіть одного iPhone вистачить для 
22 
ЧДТУ.232201.001 ПЗ 
початкового налаштування системи та простої автоматизації. Локальне 
управління системою можливе через вимикачі, кнопки та пультів [15]. 
Принцип роботи розумного будинку від Apple 
Цей фреймворк розроблений для інтеграції побутових пристроїв та 
максимальної автоматизації їхньої роботи. З технологічної точки зору рішення є 
простим. Проте система від Apple є закритою і передбачає використання тільки 
сертифікованих компанією елементів [18]. 
Основним ринком для Apple є США, де стандарти електропостачання 
можуть відрізнятися. Аксесуари, спеціально розроблені для HomeKit, можуть 
бути непрацездатними [18]. 
Платформа Apple HomeKit вирішує такі завдання: 
– збирає дані від встановлених та приєднаних пристроїв і моніторів. 
– управляє домашнім обладнанням. 
– виконує запрограмовані сценарії, такі як увімкнення опалення або 
кондиціонера в потрібний момент. 
– забезпечує роботу охоронної сигналізації та реєструє відвідувачів, 
передаючи інформацію користувачеві. 
– сповіщає власника про виникнення нештатних ситуацій [18]. 
– топологія 
Пристрої, які додаються безпосередньо в Apple HomeKit, підключаються 
через Bluetooth або Wi-Fi (рисунок 1.6). 
В більшості випадків діє таке правило: 
– Wi-Fi використовується для аксесуарів, які живляться зовнішнім 
джерелом електропостачання (220В). 
– Bluetooth працює від батарейок. 
– девайси ZigBee, Z-Wave, 433, 868 і т. д., додаються в HomeKit через 
шлюз, концентратор або хаб, і можуть живитися як від мережі, так і від 
батарейок [19]. 
 
23 
ЧДТУ.232201.001 ПЗ 
 
Рисунок 1.6 – Топологія Apple HomeKit зі шлюзами 
 
Шлюзи 
Apple TV, Home Pod, iPad – це повноцінні центральні вузли розумного 
будинку, які можуть керувати пристроями, що підключаються до них напряму 
через Bluetooth та Wi-Fi [19]. 
Якщо з'єднати розумний дверний замок з Hub за допомогою Bluetooth, 
сигнал може стати слабким, особливо якщо пристрої розташовані на відстані 
один від одного. У цьому випадку ви не матимете можливості віддалено відкрити 
двері [19]. Пристрої, які працюють за протоколом Bluetooth, не потребують 
наявності роутера, тому, наприклад, коли ви повертаєтеся додому і світло 
вимкнене, ви все одно зможете відкрити замок [19]. 
Віддалений доступ 
Для використання віддаленого управління необхідний "Домашній центр", 
яким може слугувати iPad (iOS 10 або вище), Home Pod або Apple TV. Це 
дозволяє об'єднати всі підключені пристрої для доступу ззовні [19]. 
Якщо вам потрібен віддалений доступ чи автоматизація , вам слід придбати 
Apple TV, iPad або Home Pod, оскільки програмно це наразі неможливо [19]. 
Важливо зауважити, що не всі версії Apple TV є корисними як Домашні 
центри; рекомендується використовувати Apple TV 4 і вище. Якщо в мережі 
24 
ЧДТУ.232201.001 ПЗ 
працює кілька Домашніх центрів, вони автоматично підмінять один одного 
непомітно для користувача, якщо один з них стає недоступним. Усі створені 
автоматизації синхронізуються між ними. 
Як і Apple TV, iPad і Home Pod також можуть служити як шлюзи та центри 
розумного будинку, розташовані у мережі [19]. 
Сценарії 
HomeKit включає корисну функцію сценаріїв, яка дозволяє групувати 
пристрої одного типу і керувати ними однією кнопкою. В автоматизації можна 
також прив'язувати їх до конкретних подій [19]. 
Автоматизації 
Використовуючи Домашній центр в HomeKit, ви можете створювати різні 
автоматизації [19]: 
– автоматизація при приході/виході з будинку, наприклад: "Якщо хтось 
приходить додому, то ...". 
– автоматизація за часом, наприклад: "Вимкнути світло о 22:30". 
– автоматизація за станом датчика, наприклад: "Якщо датчик спрацював, 
то ...". 
Наприклад, при виході з дому, iPhone знаходить це за допомогою геолокації 
та запускає сценарій "Виходжу з дому". Відповідно, в HomeKit відключаються 
пристрої, які були додані до цього сценарію. Тим, хто хоче більше можливостей, 
ніж надає стандартний функціонал HomeKit, може скористатися сторонніми 
додатками для створення автоматизацій, які працюють з нативним фреймворком 
HomeKit. Ці додатки дозволяють зберігати автоматизації навіть після видалення 
додатка [19]. 
Siri надає можливість керувати всіма пристроями за допомогою голосу, 
навіть коли вас немає вдома. Вона також може надавати інформацію про стан 
всіх пристроїв. Ця функція працює на iOS, macOS, watch OS, але на Apple TV та 
Home Pod можливість використовувати її є лише англійською мовою [19]. 
25 
ЧДТУ.232201.001 ПЗ 
Наприклад, якщо ви звернетесь до Siri і скажете: "Увімкни світло в дитячій 
кімнаті", вона розуміє, що ви маєте на увазі світильник в кімнаті "Дитяча" і назве 
його "Світло" [19]. 
Додаток "Будинок" також надає можливість ділитися своїм будинком з 
членами сімейного доступу та гостями [19]. 
Зауважимо, що можна обмежити використання Siri лише в тому випадку, 
коли пристрій підключений до домашньої мережі, що особливо актуально для 
гостей. З іншого боку, недоліком є відсутність можливості передачі управління 
конкретними пристроями [19]. 
Механізми безпеки і захисту в Apple HomeKit 
Apple HomeKit володіє високими стандартами безпеки для контролю 
розумного будинку. Це забезпечується за допомогою особливого методу 
шифрування для передачі оперативних даних від пристрою iOS, який здійснює 
управління, до розумних пристроїв і навпаки [20]. 
У кодовому ядрі HomeKit використовується крос-шифрування, що означає, 
що дані передаються так, що лише ті, хто безпосередньо бере участь у цьому 
"спілкуванні", можуть отримати доступ до конфіденційної інформації та даних 
[20]. 
Для прикладу, якщо ви використовуєте свій iPhone для управління 
розумним будинком через додаток Home, інформація і можливості керування 
пристроями будуть доступні лише вам як власникові. Жодна стороння особа не 
зможе перехопити інформацію, подавати підроблені команди та отримувати 
контроль над автоматизацією вашого будинку [20]. 
Плюси і мінуси HomeKit 
HomeKit має свої переваги та недоліки [19]: 
– простота використання: для інтеграції сумісного пристрою з програмою 
управління не потрібні глибокі знання в техніці або програмуванні. 
– інтеграція з системою Rubetek дозволяє придбати доступні пристрої, які 
можуть не бути прямо пов'язаними з HomeKit, але з легкістю 
інтегруються через додаток. 
26 
ЧДТУ.232201.001 ПЗ 
– можливість управління будь-яким мобільним пристроєм Apple. 
– голосовий помічник Siri розпізнає команди майже бездоганно. 
– гарантія високої якості, оскільки всі пристрої, що працюють з HomeKit, 
проходять обов'язкову сертифікацію фахівців Apple. 
Серед недоліків можна визначити такі: 
– обмежений вибір сумісних пристроїв. 
– висока вартість приладів, що сумісні з HomeKit. 
– недостатня інтелектуальність системи, яка базується на реалізації 
певних заданих сценаріїв, і хоча вони можуть бути дещо складними, 
поки що рано говорити про повну інтелектуальність програми; це, 
скоріше, автоматизована система управління з інтегрованими 
приладами. 
Xiaomi Smart Home 
Система від Xiaomi є значно більш різноманітною. Тут представлені 
Zigbee-пристрої, які підключаються до шлюзу, такі як датчики, лампочки, 
розетки і вимикачі. Є кілька різних шлюзів, і найпопулярніший з них, Mijia 
Gateway (рисунок 1.7), вставляється безпосередньо в розетку і функціонує як 
щось середнє між нічником і радіоточкою.  
 
 
Рисунок 1.7 – Xiaomi Mijia Gateway 
27 
ЧДТУ.232201.001 ПЗ 
Він може самостійно брати участь у автоматизації, вимірюючи 
освітленість, управляючи підсвічуванням, запускаючи радіостанції. Проте його 
основна функція - об'єднувати кілька пристроїв одного протоколу в загальну 
мережу, і загалом його можна підключити до 64 пристроїв. 
Існує ще один варіант шлюзу - Aqara Gateway, що зовні подібний до 
першого. Внутрішні відмінності мінімальні, адже вони видалили лише підтримку 
інтернет-радіо. Однак цей варіант пропонує європейську виделку (не потрібні 
адаптери) і, що є найважливішим, підтримує інтеграцію з системою Apple 
HomeKit. 
Третій тип шлюзу, Aqara A/C Companion, не здобув особливої популярності 
за межами Китаю. Він має зовнішній вигляд розетки для підключення техніки з 
"китайським" вилком та інфрачервоні світлодіоди замість підсвічування. 
Функціонально цей пристрій виступає як універсальний пульт для техніки, яка не 
підтримує Wi-Fi підключення [21]. 
Окрім технології Zigbee, у Xiaomi також є самостійні пристрої з 
підтримкою Wi-Fi. Зазвичай це важкі технічні пристрої, які вимагають широкого 
каналу для передачі даних, такі як роботи-пилососи, холодильники, мультиварки 
і т.д. Однак в асортименті також є прості лампочки та розетки, які можуть бути 
ідеальним вибором для тих, хто створює "розумний будинок на мінімалку" без 
складних сценаріїв. У такому випадку не потрібно покупати жодного шлюзу, але 
вся взаємодія буде відбуватися через інтернет, без можливості локального 
управління [21]. 
В системі Mi Home також існує певна кількість Bluetooth-пристроїв, які, як 
правило, є допоміжними. Серед них датчики, пульти і інше обладнання. Декотрі 
замки дверей також працюють по Bluetooth. Ці пристрої можна підключати 
безпосередньо до смартфону, але багато з них мають свій власний окремий 
додаток. Якщо є потреба у дистанційному керуванні ними і уникненні постійного 
підключення до телефону, можна скористатися Bluetooth-шлюзом. Деякі інші 
пристрої екосистеми, такі як нічник Mijia Bedside Lamp і зволожувач повітря 
Smartmi Air Humidifier, також можуть виконувати цю функцію [21]. 
28 
ЧДТУ.232201.001 ПЗ 
 
Рисунок 1.8 – Архітектура «Розумного будинку» Xiaomi 
 
Принцип роботи розумного будинку Xiaomi базується на створенні 
інтелектуального комплекту електроніки Smart Kit Home, який можна придбати у 
вигляді готового набору для підключення (рисунок 1.8). Його склад включає 
центральний хаб, дистанційну кнопку, камеру відеоспостереження, 
електромагнітний детектор відкриття вікон і дверей, датчик руху, кріплення-
липучки для установки елементів системи, а також пристосування для скидання 
налаштувань [22]. Крім того, існують інші різновиди хабів від дочірніх компаній 
Xiaomi, таких як Mijia і Aqara [22]. 
Основним принципом функціонування будь-якого варіанту "розумного 
будинку" від Xiaomi є використання специфікації протоколів ZigBee. Ця 
специфікація представляє собою окрему мережу, подібну до Bluetooth або Wi-Fi, 
що діє як надбудова до базового стандарту IEEE 802.15.4. Забезпечуючи 
стабільний зв'язок з датчиками, ця мережа є ключовою для нормальної роботи 
системи. Ще однією перевагою ZigBee є низька енерговитратність, що дозволяє 
"розумному будинку" працювати в автономному режимі протягом тривалого 
часу. Наприклад, датчик Smart Kit Home може працювати на одному елементі 
29 
ЧДТУ.232201.001 ПЗ 
живлення в 3 вольти приблизно 1,5 року, незалежно від того, який з підрозділів 
компанії випустив хаб і розумний пристрій – Mijia або Aqara. Всі вони мають 
відмінну взаємодію завдяки протоколу ZigBee [22]. Недоліки специфікації 
ZigBee, такі як обмежений радіус дії і низька пропускна здатність для системи 
"розумний будинок", не є критичними. Однак інтерфейс ZigBee не підтримує 
сучасні мобільні пристрої, тому для надсилання команд через смартфон або 
планшет потрібне підключення до шлюзу через Bluetooth або Wi-Fi. Хаб Air 
Conditioning може також управляти розумними датчиками за допомогою 
інфрачервоного зв'язку і голосових команд [22]. 
Щодо мобільних пристроїв, шлюз може працювати через Wi-Fi-роутер, 
віддалений від нього, згідно з технічним паспортом, на відстань не більше 2-3 
метрів, хоча насправді ця відстань може сягати до 5 метрів. Хаби Mijia і Aqara 
сумісні з мобільними пристроями, що працюють на Android і iOS, і на екрані 
смартфона або планшета можна відображати інформацію про підключені 
пристрої, магазин для покупок нового обладнання та профіль для управління 
аккаунтом та перегляду офіційних повідомлень компанії [31]. 
1.4 Рівнева архітектура інтернету речей 
На рисунку 1.9 зображено структуру рішень Інтернету речей (IoT) [9]. 
Фізичний рівень – це рівень фізичної реалізації. 
На цьому рівні виконуються дві основні операції: збір інформації та 
виконання механічних робіт. Фізичні елементи повинні відповідати певним 
загальним вимогам [9]: 
– доступність за низьку ціну; 
– живлення від батарейки; 
– розташування в важкодоступних і віддалених місцях з мінімальними 
витратами на установку і обслуговування; 
– здатність до первинної обробки зображень і прийняття рішень на основі 
штучного інтелекту. 
30 
ЧДТУ.232201.001 ПЗ 
 
Рисунок 1.9 – Рівнева архітектура IoT рішень 
 
Існує дві ключові проблеми для вимог фізичного рівня [9]: 
– ефективне споживання енергії; 
– використання відеокамер. 
Рівень периферійного обчислення – це рівень, що забезпечує локальне 
оброблення даних. 
Цей рівень зазвичай підключений до одного датчика або виконавчого 
механізму. Він забезпечує базовий функціонал для перетворення аналогової 
інформації в цифрову та навпаки. Багато виробників цих пристроїв не мають 
єдиного стандарту для моделі даних, конфігурації та експлуатації [9]. 
З метою зменшення енергоспоживання периферійні пристрої функціонують 
у чотирьох режимах: 
– сон; 
31 
ЧДТУ.232201.001 ПЗ 
– вимірювання та збір інформації з датчиків; 
– зв'язок, передача та отримання інформації; 
– установка та підключення. 
Нижче подана блок-схема периферійного пристрою. 
Периферійний пристрій інтегрує три рівні: фізичний, рівень периферійного 
обчислення та комунікаційний. Основне призначення рівня периферійного 
обчислення - це локальний процес ETL (видобуток, трансформація та 
завантаження) - отримання, перетворення та зберігання інформації від датчиків. 
Цей рівень відповідає за фільтрацію перешкод, попередній аналіз та локальне 
зберігання [9]. 
Рівень периферійної комунікації - це етап передачі даних, який є найбільш 
енергоефективним для периферійних пристроїв, оскільки вони часто не 
підключені до електромережі та провідних засобів зв'язку. Крім того, ці пристрої 
можуть бути розташовані на значній відстані від шлюзу. Незважаючи на це, обсяг 
передаваної інформації зазвичай невеликий. На рівні периферійної комунікації 
використовуються наступні протоколи [9]: 
– ZigBee/Z-wave; 
– BLE; 
– Lora; 
– Пропрієтарний протокол низької частоти. 
Для забезпечення більшої відстані і надійності зв'язку на цьому рівні 
широко застосовуються технології Ad Hoc і Mesh. Протокол NFC також може 
використовуватися для конфігурації, наприклад, під час першої установки або 
технічного обслуговування, коли сервісний інженер з мобільним додатком 
підключається до периферійних пристроїв через рівень периферійної комунікації. 
У деяких випадках також використовується QR-код, розміщений на 
периферійному пристрої, для аутентифікації [9]. 
Рівень шлюзу – це етап в IoT-рішенні, який визначений кількома 
причинами: 
32 
ЧДТУ.232201.001 ПЗ 
– неподання обробленої інформації Backend може призвести до великих 
витрат потужності; 
– робота Backend не може гарантувати реакцію в реальному часі для 
значної кількості периферійних пристроїв; 
– з міркувань безпеки деяка інформація, наприклад, дані 
відеоспостереження або медична інформація, не може постійно 
відправлятися в Backend і контролюватися центрально.  
Шлюз виконує основні завдання: 
– виконує другий етап ETL для своїх периферійних пристроїв; 
– реагує на критичні ситуації і забезпечує локальну реакцію, навіть без 
зв'язку з Backend - це можна порівняти з автономними функціями серця 
або легень; 
– спілкується з Backend, відправляє оброблену інформацію від 
периферійних пристроїв та отримує конфігураційні дані для 
периферійних пристроїв; 
– зберігає інформацію про статус периферійних пристроїв і зібрані ними 
дані. 
У деяких випадках на рівні шлюзу може бути використана 
функціональність штучного інтелекту / машинного навчання. Шлюз живиться від 
електромережі або має велику вбудовану батарею, іноді вимагається також 
низьке енергоспоживання [9]. 
У найближчому майбутньому можна очікувати подальшу інтеграцію всіх 
трьох компонент: шлюз + STB + системи безпеки в один пристрій. Також 
ймовірно, що він буде обладнаний службами NAS (локального зберігання файлів) 
та функціональністю AI/ML для машинного відео/аудіо розпізнавання. Важливо 
зазначити, що пристрої для розпізнавання мови, такі як Alexa, зазвичай базуються 
на хмарній інфраструктурі, але ймовірно, що первинне розпізнавання буде 
виконуватися на рівні периферійного пристрою [9].  
Рівень зовнішнього зв'язку – це логічний етап зовнішнього зв'язку для 
стандартізації протоколу в рішеннях IoT, відомий як LvM2M. Цей протокол 
33 
ЧДТУ.232201.001 ПЗ 
розроблений для доступу до кожного периферійного пристрою. Однак, оскільки 
багато постачальників периферійних пристроїв не підтримують інтерфейси 
LvM2M, шлюзовий пристрій вирішує цю проблему, створюючи обгортку для 
взаємодії з периферійними пристроями [9]. Рівень зовнішнього зв'язку включає 
комунікаційні послуги, такі як балансування навантаження для визначення 
місцезнаходження, базоване на DNS сервісі, транспортний протокол COAP, 
шифрування DTLS і інші компоненти [9]. 
Протокол LvM2M використовує шифрування DTLS, яке забезпечує безпеку 
ключів і встановлює з'єднання за допомогою протоколу handshake. Цей протокол 
працює в режимі точка-точка. Для розшифрування пакетів DTLS 
використовується той самий екземпляр Backend, який був використаний під час 
сесії з'єднання. Це може становити проблему для балансувальника навантаження 
(Load Balancer), який є частиною рівня безпеки. Load Balancer необхідний для 
автоматичного масштабування при високому завантаженні системи. Для 
уникнення цього обмеження використовується служба DNS в якості Load 
Balancer. Кожен DNS-запит отримує новий IP-адрес для екземпляра рівня безпеки 
[9; 36]. 
Рівень аналітики Big Data and Analytic – це залежність від конкретного 
застосування IoT. Він отримує ситуативну інформацію від усіх периферійних 
пристроїв. Цей рівень менше стандартизований, оскільки він суттєво 
відрізняється від одного додатка до іншого через різноманітні завдання рішень. 
Також на цьому рівні широко використовуються алгоритми штучного інтелекту 
та машинного навчання. Окремою категорією є передбачення майбутніх подій, 
таких як запаси на складі, споживання ресурсів у майбутньому, погода [9]. 
Рівень повідомлень Notification – це етап, на якому може існувати кілька 
компонентів, але всі вони використовують алгоритм повідомлення за 
передплатою. Клієнтська програма підписується на необхідні події, і коли вони 
відбуваються, отримує інформаційний сигнал у вигляді повідомлення. Зазвичай 
це включає в себе електронну пошту і мобільні додатки, а також телефонні 
дзвінки для екстреного оповіщення. Мобільні додатки переходять в сплячий 
34 
ЧДТУ.232201.001 ПЗ 
режим для збереження енергії, але операційні системи iOS і Android мають 
механізми повідомлень для позначення прибуття нових даних [9]. 
Рівень представлення Presentation – це етап, на якому додаток IoT може 
мати два потоки: M2M та M2P. Рівень представлення, що пов'язаний з потоком 
M2M, включає в себе обробку інформації Backend та надання її клієнтам або 
інженерам служби підтримки. Він також відповідає за обслуговування, 
конфігурацію і зміни стану системи, включаючи периферійні пристрої та шлюзи. 
Рівень представлення включає команди для управління виконавчими 
механізмами периферійних пристроїв [9]. 
Рівень конфігурації Configuration – це етап, який стосується обох потоків - 
M2M і M2P, і працює як сховище для трьох типів статусів периферійних 
пристроїв: актуальний, новий та проміжний статус. Периферійні пристрої і 
шлюзи мають короткий час підключення до Backend, і будь-які зміни статусу від 
клієнта або системи зберігаються на цьому рівні, а протягом часу зв'язку вони 
відправляються на шлюз або периферійний пристрій [9]. 
Узагальнюючи, можна визначити деякі тенденції розвитку в IoT-рішеннях: 
– датчики поділяються на дві групи: прості та дешеві з низьким 
споживанням енергії та великою дальністю передачі інформації, та ті, 
які інтегровані з відеокамерою та володіють механізмами розпізнавання 
образів. 
– процеси ETL відбуваються на кількох рівнях: на периферійних 
пристроях, у шлюзах та на рівні Backend. Немає єдиного підходу до 
обробки на кожному рівні, але загальна ідея - обробка має відбуватися 
на найнижчому рівні, де це можливо. 
– бездротовий інтернет виступає основним засобом передачі інформації, 
хоча протоколи можуть різнитися на різних рівнях. Логічний рівень 
зв'язку використовує протокол LvM2M. 
– більшість Backend-систем використовують хмарні технології, і AWS є 
популярним вибором. 
35 
ЧДТУ.232201.001 ПЗ 
– мобільні додатки використовуються для відображення фактичної 
інформації, тоді як WEB-додатки представляють аналітичну 
інформацію. 
Висновки до розділу 1 
Розумний будинок – це архітектурна концепція, яка об'єднує передові 
технології для створення інтелектуального житлового простору. Цей тип будівлі 
використовує різноманітні технології, такі як інтернет речей (IoT), штучний 
інтелект (ШІ), датчики та системи автоматизації, з метою оптимізації різних 
аспектів повсякденного життя. Одним із ключових аспектів є інтеграція IoT, що 
дозволяє побутовим пристроям комунікувати між собою та з центральною 
системою. Наприклад, термостат може взаємодіяти з датчиками температури та 
вікнами, регулюючи опалення для оптимального комфорту та ефективності 
енергоспоживання. 
Штучний інтелект використовується для аналізу даних та вивчення звичок 
мешканців, щоб автоматично адаптувати параметри будинку до їхніх потреб. 
Наприклад, система може самостійно регулювати освітлення та температуру в 
кімнатах відповідно до розкладу дня чи особистих уподобань. 
Додатково, розумний будинок може включати системи безпеки, які 
використовують камери та сенсори для миттєвого виявлення небезпеки або 
незвичайної активності. Ця архітектурна концепція визначається своєрідним 
комбінуванням технологій з метою поліпшення комфорту, безпеки та 
енергоефективності в житті мешканців, відображаючи напрямок розвитку 
сучасної будівельної індустрії. 
36 
ЧДТУ.232201.001 ПЗ 
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
2.1 Теоретичні дослідження  
Найпоширенішою формою розповсюдження програмного забезпечення є 
модель ліцензування програмних продуктів. Ліцензійне програмне забезпечення 
включає всі програмні продукти, які є власністю третьої сторони та ліцензуються 
та використовуються іншими компаніями чи фізичними особами для свого 
бізнесу чи особистих потреб [98]. Використання цієї моделі дозволяє 
розробникам програмного забезпечення захищати свої права на інтелектуальну 
власність від піратства та отримувати винагороду за використання свого 
продукту. Однак для користувачів програмного забезпечення це означає, що вони 
повинні оплатити продукт для отримання прав на його використання на певний 
термін дії ліцензії або безстроково. 
В контексті систем "розумного" будинку використання цієї моделі стає 
суттєвим негативним аспектом. Покупець зобов'язаний оплатити повну вартість 
програмного продукту, незалежно від інтенсивності його подальшого 
використання, включаючи ситуації, коли використання програмного продукту 
стає непотрібним через зміни в бізнес-стратегії, тимчасові обмеження або простій 
приміщень під час пошуку нових орендарів. Більшість ліцензій обмежують право 
використання лише одного екземпляра програмного продукту на одному 
комп'ютері, що створює труднощі для масштабування системи "розумного" 
будинку або для переходу до іншого обчислювального пристрою. 
Визначення апаратних витрат на обрахунок операції (2.1). Виконаємо 
визначення обчислювальної складності. Фізичний час для обрахунку алфавітів 
для методу еліптичних кривих визначається як (рисунок 2.1): 
 
n + n 2
T (n) = b k
     (2.1) 
A
fCPU
 
37 
ЧДТУ.232201.001 ПЗ 
де n – розмірність очікуваного алфавіту; 
 b  – операційна складність обрахунку одної букви алфавіту;  
k  – кількість операцій для виконання математичної операцій пошуку; 
CPU f – швидкодія процесора.[50] 
 
 
Рисунок 2.1 – Реалізація алгоритму підведення в ступінь ab 
 
Цей підхід також ускладнює можливість віддаленого використання 
програмного продукту в разі відсутності можливості фізично перебувати біля 
комп'ютера з встановленим ліцензованим програмним забезпеченням. Оскільки 
обновлення програмного забезпечення важливо для забезпечення безпеки та 
функціональності систем "розумного" будинку, більшість ліцензій не 
задовольняють вимогам до швидкого та ефективного оновлення, що є необхідним 
в цьому швидкозмінному сегменті технології. У зв'язку з цим у сфері систем 
"розумного" будинку розглядається використання моделі SaaS (software as a 
service) як способу вирішення цих проблем [19]. SaaS є однією з найбільш 
популярних моделей хмарних обчислень на сьогодні. Основна ідея полягає в 
тому, що користувачам надається готове до використання програмне 
забезпечення, яке повністю обслуговується провайдером. У цій моделі провайдер 
самостійно управляє програмним забезпеченням, надаючи користувачам доступ 
до його функцій через клієнтські пристрої (рисунок 2.2). Основною перевагою 
38 
ЧДТУ.232201.001 ПЗ 
SaaS для користувачів є відсутність витрат на встановлення, оновлення та 
підтримку програмного забезпечення [8]. 
 
 
Рисунок 2.2 – Схема моделі поширення програмного забезпечення SaaS 
 
З точки зору розробників, ця модель надання послуг дозволяє ефективно 
боротися з неліцензійним використанням програмного забезпечення. Користувачі 
не отримують доступ до програмного коду системи, а лише до кінцевих точок 
входу і виходу функцій. Це сприяє інкапсуляції та прихованій реалізації даних 
функцій, які виконуються на стороні провайдера [106]. Модель SaaS також 
дозволяє зменшити витрати на розгортання, інтеграцію та підтримку технічної 
частини системи. Застосування SaaS у сфері систем "розумного" будинку не 
вимагає авансових витрат на придбання ліцензій, що дозволяє клієнтам обирати 
лише ті функції, які їм потрібні, без необхідності придбання всього пакету. Це 
39 
ЧДТУ.232201.001 ПЗ 
зменшує фінансовий ризик, оскільки користувачі можуть вибрати оплату лише за 
певний період часу або конкретну функціональність. Підписки можна припинити 
в будь-який момент. 
SaaS дозволяє отримувати доступ до програмного продукту з будь-яких 
пристроїв з Інтернет-з'єднанням, що забезпечує мобільність і оперативність в 
налаштуванні програмного забезпечення. Оновлення встановлюються 
централізовано на сервері провайдера, що забезпечує швидке отримання 
виправлень вразливостей [99]. Користувачам не потрібно вручну завантажувати 
та встановлювати патчі, що спрощує використання систем "розумного" будинку 
та знижує необхідність в технічній обізнаності. 
Використання моделі SaaS з фінансового погляду має важливу перевагу, 
оскільки дозволяє переносити "важкі" обчислення на технічні ресурси серверів 
провайдера. Прості та економічні технічні рішення можуть використовуватися 
клієнтами для передачі вхідних даних та отримання обчислених результатів 
роботи сервера для окремих функцій системи "розумного" будинку [107, 108]. 
Цей підхід значно зменшує вартість встановлення систем "розумного" будинку 
для кінцевих користувачів, що призводить до скорочення їхніх витрат на 
апаратне забезпечення системи. Серед основних функцій "розумного" будинку є 
управління освітленням будинку, включаючи керування окремими групами 
приладів освітлення та встановлення відповідного рівня освітлення в окремих 
частинах будинку [109]. Крім того, до таких функцій входить управління 
жалюзями та шторами за допомогою електродвигунів, регулювання 
температурного режиму в кімнатах та керування медіа-пристроями. Менш 
поширеними, але також важливими є функції системи безпеки, яка повідомляє 
про проникнення нерозпізнаних осіб та інші аспекти [11]. Однак повне 
перенесення всього функціоналу системи "розумного" будинку на модель SaaS є 
недоцільним у зв'язку з можливими перебоями та затримками в інтернет-
з'єднанні, що може вплинути на отримання команд для виконання. Розподіл 
функціоналу між клієнтською та серверною стороною надає переваги, такі як 
40 
ЧДТУ.232201.001 ПЗ 
зменшення навантаження на апаратне забезпечення клієнтської сторони та доступ 
до великих обсягів реальних даних. Це дозволяє зменшити вартість обладнання 
та встановлення для кінцевого користувача [13]. 
В свою чергу, великі об'єми реальних даних можуть використовуватися для 
поліпшення аналізу та виправлення помилок у роботі системи. Також ці дані 
можуть бути використані для оптимізації методів машинного навчання, які 
використовуються для автоматизованого прийняття рішень у функціонуванні 
системи "розумного" будинку. У випадку систем "розумного" будинку 
ключовими даними є оптимальні температурні показники в кожній кімнаті 
будинку, залежні від різних факторів, таких як присутність людей, пора року, час 
доби та температура навколишнього середовища. 
Автоматизоване управління температурним режимом та освітленням в 
системах "розумного" будинку дозволяє налаштовувати параметри термостатів та 
освітлення відповідно до вподобань користувачів без їхньої прямої участі. Це 
сприяє суттєвій економії фінансових витрат на опалення та освітлення завдяки 
оптимальному використанню ресурсів у тих частинах будинку, де вони потрібні, 
зберігаючи ресурси у непотрібних частинах будинку [15]. 
Ця функціональність ґрунтується на алгоритмах машинного навчання, для 
яких необхідні навчальні дані. Тому перенесення цих даних на сторону 
провайдера сприяє поліпшенню результатів автоматизованого прийняття рішень, 
оскільки система навчається на реальних даних. Схема розподілу локальних та 
хмарних функцій зображена на рисунку 2.3. 
Розподіл функцій у системі "розумного" будинку відбувається з 
урахуванням значень параметрів обчислювального навантаження 
(високонавантажена/низьконавантажена), часу, необхідного для отримання 
результату обчислення (термінова/нетермінова), критичності відмови роботи 
конкретної функції для повноцінного функціонування системи 
(критична/некритична), а також параметра частоти запитів обчислення логіки 
роботи функції (високочастотна/низькочастотна). 
41 
ЧДТУ.232201.001 ПЗ 
 
Рисунок 2.3 – Схема розподілу локальних функцій та функцій у хмарі 
 
Однією з ключових економічних переваг використання моделі SaaS є 
можливість масштабування системи, що базується на цій моделі. Постачальник 
послуг обслуговує єдине програмне ядро, яке використовується клієнтами, тому 
витрачає менше ресурсів порівняно з управлінням окремими копіями 
програмного забезпечення для кожного користувача. Крім того, використання 
єдиного програмного ядра дозволяє оптимізувати використання технічної 
потужності між користувачами. Це сприяє суттєвому зниженню вартості 
експлуатації програмного забезпечення, тому вартість послуг для кінцевого 
користувача такої системи стає менше, ніж у класичній моделі ліцензування. Ще 
однією перевагою використання моделі SaaS у системах "розумного" будинку є 
швидкість виправлення недоліків програмного забезпечення та вразливостей 
системи. Це досягається тим, що проблема, що виникла у конкретного 
42 
ЧДТУ.232201.001 ПЗ 
користувача, буде виправлена у єдиному ядрі. Це запобігає потенційному 
виникненню цієї проблеми у решти користувачів без необхідності встановлення 
відповідних оновлень для кожного окремого екземпляру програмного 
забезпечення, встановленого на апаратній частині користувачів. Додатково, при 
додаванні нового функціоналу до системи, оновлення системи стає доступним 
одночасно для всіх користувачів. Взаємодія між клієнтами системи та 
програмним ядром системи здійснюється за допомогою шлюзу програмного 
інтерфейсу (рисунок 2.4). 
 
 
Рисунок 2.4 – Схема комунікації програмного ядра та клієнтів системи 
 
Можливість централізованого використання даних, що надходять з різних 
екземплярів систем "розумного" будинку, встановлених у різних середовищах з 
різними видами активності та рівнем інтенсивності користування системою, 
значно розширює та різноманітнює навчальну вибірку для використання 
алгоритмами машинного навчання. Це призводить до підвищення точності 
автоматизованого прийняття рішень у ситуаціях, які не є характерними для 
конкретної системи, але виникали у системах інших користувачів. На додаток до 
факторів, що спонукають замовників використовувати програмне забезпечення у 
вигляді сервісу, а розробників – інвестувати ресурси у його створення, існує ряд 
обмежуючих факторів, які обмежують використання даної моделі. Економія 
43 
ЧДТУ.232201.001 ПЗ 
ресурсів Saas-провайдерів досягається завдяки масштабуванню, тому Saas-модель 
неефективна для систем, що потребують глибокої індивідуалізації та адаптації 
під конкретного замовника. Також багато замовників можуть відчувати 
неуспокоєність застосування Saas моделі через питання безпеки та можливого 
витоку інформації від постачальника Saas-послуг. Проблеми, пов'язані з 
безпекою, обмежують використання SaaS-моделі в системах, де обробляється 
конфіденційна інформація, а системи "розумного" будинку, як правило, 
працюють із такими даними. Ще одним критичним фактором, що обмежує 
використання даної моделі, є необхідність постійного підключення до Інтернету. 
Частковим вирішенням цієї проблеми є використання на стороні клієнтів 
додаткових програмних модулів для автономної роботи, які діють як резервне 
"джерело" прийняття автоматизованих рішень системою. Однак ці модулі мають 
спрощену логіку лише для забезпечення життєдіяльності системи на 
короткотривалий період від'єднання від серверів провайдера послуг. 
2.2 Ефективність опрацювання даних у системах «розумного» будинку 
Системи "розумного" будинку постійно розвиваються, привносячи з собою 
дві важливі тенденції. З одного боку, інтелектуалізація їхніх функцій набуває все 
більшого значення, а з іншого – спостерігається збільшення їхньої розмірності, 
включаючи кількість компонентів, таких як датчики, актуатори, мікроконтролери 
і т. д. Розробка та аналіз таких систем стають неможливими без використання 
сучасних технологій проектування. Вимоги до систем "розумного" будинку 
неперервно зростають, при цьому розробники цих систем мають справлятися зі 
зростаючою кількістю станів системи в різні моменти її роботи. 
Ці стани включають в себе дані, отримані від вбудованих датчиків у 
будинку, а також збережені історичні дані цих датчиків і інформацію, що 
генерується системою під час її роботи, наприклад, команди зміни режимів 
роботи побутових приладів у будинку. 
Написання логіки управління станами системи, яка часто піддається 
змінам, є складною частиною процесу розробки систем "розумного" будинку, 
44 
ЧДТУ.232201.001 ПЗ 
вимагаючи значних зусиль і фінансових ресурсів. Наприклад, якщо значення 
стану датчика вимагає зміни режиму роботи побутового приладу, це може 
призвести до зміни значення стану іншого датчика, що, в свою чергу, може 
вимагати зміни режиму іншого побутового приладу в будинку. 
Стан системи формується на основі записів параметрів усіх підключених до 
системи датчиків, внутрішніх змінних логіки роботи та значень налаштувань 
приладів, якими система управляє. 
На певному етапі розробки програмного забезпечення для систем 
"розумного" будинку виникає ситуація, коли проектувальники втрачають 
здатність відслідковувати внутрішню логіку роботи системи та втрачають 
контроль над тим, коли, чому і як оновлюються стани системи. Це непрозоре 
функціонування системи створює великі ризики щодо її надійності, швидкості 
виявлення та виправлення помилок в логіці та можливості додавання нових 
функцій. Складність виникає через змішування двох різних концепцій: змін і 
асинхронності. 
Термін "зміни" означає потік показників даних датчиків, які генеруються в 
режимі реального часу і впливають на зміни налаштувань побутових приладів у 
будинку. Асинхронність полягає в неперіодичному виникненні подій, наприклад, 
рух людини або зміна температури в кімнаті, що не залежать від часових 
інтервалів і не мають чіткого графіка. 
Для вирішення цих проблем пропонується використовувати архітектурний 
шаблон Redux, адаптований до потреб розробки систем "розумного" будинку. У 
літературі проблеми швидкодії систем, які опрацьовують велику кількість 
одночасних подій, обговорюються з використанням різних архітектурних 
підходів, таких як монолітні, мікросервісні, багаторівневі та Flux архітектури. 
Кожен підхід має свої переваги та недоліки залежно від характеру інформаційної 
системи. Системи "розумного" будинку, з їх великою кількістю одночасних 
подій, можуть скористатися різними архітектурними рішеннями, такими як 
монолітні, мікросервісні, багаторівневі та Flux архітектури (рисунок 2.5). 
Специфіка використання обраного підходу буде оцінена на основі тестових 
45 
ЧДТУ.232201.001 ПЗ 
даних, що дозволить вибрати оптимальне рішення для системи "розумного" 
будинку. 
 
 
Рисунок 2.5 – Алгоритм вибору архітектурного рішення в процесі синтезу 
системи 
 
Найшвидші показники ефективності системи були отримані при 
впровадженні архітектурного шаблону Redux, який входить до системи Flux. З 
іншого боку, система працювала найповільніше, коли використовувалася 
монолітна архітектура. 
Redux - це архітектурний шаблон управління станом даних, розроблений 
для веб-додатків. Він ідеально підходить для систем, де управління станом може 
стати складним і заплутаним з часом. Цей шаблон не обмежений конкретним 
46 
ЧДТУ.232201.001 ПЗ 
фреймворком і спочатку був створений для бібліотеки React для розробки 
візуальних інтерфейсів. 
Redux пропонує зберігати загальний стан параметрів системи в 
централізованому "сховищі". Компоненти системи, такі як сенсори та побутові 
прилади, "відправляють" зміни стану в це сховище, а не безпосередньо до інших 
компонентів. Це рішення допомагає уникнути плутанини в джерелах 
відправлення даних та забезпечити правильність потоків даних у системі, 
особливо при розширенні функціоналу системи. Кожен компонент, який має бути 
в курсі цих змін, "підписується" на сховище. 
Такий підхід, за допомогою архітектурного шаблону Redux, робить потік 
даних зрозумілим для подальшого опрацювання відповідно до реалізованої 
логіки програмного забезпечення системи "розумного" будинку. Основні 
концепції Redux включають події, сховище та редюсери. Події є структурами 
даних, які передають дані в сховище і представляють інформацію про 
виникнення ситуацій, таких як спрацювання датчика чи команди користувача. 
Сховище є об'єктом, який засібдає стан системи, надаючи доступ до цього 
стану. Воно може оновлювати стан системи і дозволяє реєструватися в якості 
"слухача" для отримання оновлень стану системи після змін. Redux використовує 
лише одне сховище для всього стану параметрів системи, назване "сховищем". Це 
сховище виступає єдиною точкою правди, оскільки в ньому знаходиться весь 
стан. 
Структура даних сховища повністю залежить від розробників системи 
«розумного» будинку, але вона, як правило, представляє собою об'єкт з 
декількома рівнями вкладеності. Сховище стану системи зберігається у базі 
даних системи і не залежить від типу моделі бази даних (реляційна/нереляційна) 
або ступеня її розподіленості (централізована/розподілена). Однак основною 
вимогою до сховища є надання стандартизованого інтерфейсу взаємодії, що 
дозволяє отримувати, оновлювати та підписуватися на частину або весь стан 
сховища. 
47 
ЧДТУ.232201.001 ПЗ 
Внутрішня структура сховища поділяється на групи, які розмежовують дані 
залежно від типів та логічних груп даних. У системах «розумного» будинку дані 
групуються за ознаками приналежності до конкретних кімнат або типу 
збережених даних. Наприклад, в сховищі для трьохкімнатного будинку може 
бути 5 груп даних, представляючи різні приміщення: вітальня, спальня, кабінет, 
кухня і санвузол. 
 
 
Рисунок  2.6 – Схема життєвого циклу стану системи «розумного» будинку 
 
Redux запобігає компонентам системи безпосередньо змінювати стан. 
Замість цього події визначають необхідні зміни у стані системи. Редюсери є 
обробниками подій, які реагують на них і здатні змінювати сховище. Редюсер 
обов'язково приймає поточний стан системи і подію як вхідні параметри. 
Відповідно до типу події редюсер виконує логічні операції над параметрами 
поточного стану і повертає змінений стан. Редюсер, обчислюючи новий стан, 
перезаписує його в сховищі, не змінюючи поточний стан системи. Це забезпечує 
48 
ЧДТУ.232201.001 ПЗ 
чітке розмежування функцій редюсера і сховища даних. Схема життєвого циклу 
стану системи показана на рисунку 2.6. 
При отриманні події редюсер порівнює тип події з відомими йому, витягує 
поточний стан системи та, використовуючи логіку зміни стану, застосовує 
необхідні зміни до параметрів стану. Результатом є новий стан системи, який 
зберігається в сховищі, замінюючи попередній. Схема трансформації даних, яка 
ілюструє функціонування системи для підтримки температурного режиму, 
представлена на рисунку 2.7. 
 
 
Рисунок 2.7 – Схема трансформації даних 
 
Отже, розробка систем «розумного» будинку з упровадженням концепцій 
архітектурного шаблону Redux дозволяє ефективно та легко масштабувати 
систему для використання в більшій кількості приміщень у будинку. Це 
досягається завдяки впровадженню єдиного сховища стану системи та 
стандартизованому підходу до його зміни, незалежно від джерела подій, що 
виникають у будинку, при цьому не втрачаючи швидкодії роботи. 
Гіпотеза дослідження 
Гіпотеза дослідження передбачає, що вдосконалення поєднання 
архітектурного шаблону Redux та методів обробки великих обсягів даних в 
системах "розумного" будинку призведе до значного покращення швидкості та 
ефективності обробки даних у режимі реального часу. Припускаємо, що це 
досягнення буде важливим в контексті вирішення викликів, пов'язаних з 
постійними змінами та ростом потреб у сучасному житті. 
49 
ЧДТУ.232201.001 ПЗ 
Додатково, впровадження моделей поширення програмного забезпечення, 
зокрема на основі концепції Software as a Service (SaaS), призведе до покращеної 
ефективності інтеграції та оптимізації ресурсів у системах "розумного" будинку. 
Ця стратегія інтеграції має потенціал підвищити гнучкість та універсальність 
вирішення різноманітних завдань, таких як безпека, енергоефективність і багато 
інших, що є актуальними для "розумних" систем. 
Дослідження принесуть важливі висновки та рекомендації для практичного 
впровадження цих інноваційних підходів у сфері управління "розумним" 
будинком, що відобразиться на покращенні якості життя користувачів та 
оптимізації функціональності таких систем. 
2.3 Експериментальні дослідження 
Система розробленого програмного забезпечення поділяється на 
внутрішньо- та зовнішньо-системні компоненти. До внутрішньосистемних 
відносяться елементи, які включаються до клієнтської та серверної частин. До 
компонент клієнтської частини входять: модуль збору параметрів сенсорів, 
модуль перетворення параметрів, модуль головного контролера, модель 
автоматизованого прийняття рішень, модуль збереження стану компонентів 
системи, модуль управління базою даних, модель комунікації з віддаленим 
сервером, модуль управління приладами. 
До компонент серверної частини належать: модуль аналітики збережених 
даних, модель комунікації з клієнтськими частинами, модуль головного 
контроллера, модуль збереження даних від клієнтських контроллерів, модуль 
тестування роботи створених моделей, модуль управління базою даних, модуль 
навчання моделей штучних нейронних мереж. 
Зовнішньосистемні модулі включають: віддалені бази даних, мережевий 
шлюз, хостинг інтерфейсу управління сервером, модуль нотифікації 
користувачів, сенсори та прилади. 
Взаємодія між компонентами системи відбувається таким чином: 
користувач, рухаючись у приміщенні, викликає реакцію сенсорів, що в свою 
50 
ЧДТУ.232201.001 ПЗ 
чергу активує відправку сигналу до клієнтського контролера. Контроллер 
починає процес аналого-цифрового перетворення сигналу, що призводить до 
створення нового стану системи. Команди щодо змін налаштувань 
відправляються до побутових приладів у приміщенні, які відправляють 
підтвердження зміни налаштувань клієнтському контролеру. Контролер інформує 
користувача про зміни за допомогою електронної пошти, SMS та пуш-
повідомлень на мобільні пристрої. Крім того, клієнтський контролер передає дані 
про зафіксовані події та загальний стан системи серверній частині. На стороні 
серверної частини проводиться навчання моделі штучної нейронної мережі, а 
отримані дані відправляються до віддаленої бази даних для подальшого 
збереження та використання у навчальному процесі. Нова модель штучної 
нейронної мережі повертається до серверної частини для збереження та 
використання у калькуляції нових станів системи.  
Класи програмної реалізації системи відповідають основним модулям та 
компонентам як клієнтської, так і серверної частин. У складі програмних класів 
клієнтської частини включаються: клас, що відповідає за збір даних від сенсорів, 
клас для конвертації сигналів сенсорів та команд для побутових приладів, клас 
головного контролера, клас, який реалізує автоматизований процес прийняття 
рішень, клас управління базою даних, та клас для забезпечення комунікації з 
серверною частиною. 
У програмних класах серверної частини включаються: клас для аналітики 
даних, клас для комунікації з клієнтською частиною, клас головного контролера 
серверної частини, клас управління базами даних, клас для емуляції роботи 
моделей штучних нейронних мереж, та клас, відповідальний за тренування 
штучних нейронних мереж. 
Структура програмного забезпечення серверної частини розробленої 
системи ґрунтується на мікросервісному архітектурному стилі. На відміну від 
монолітного підходу, де вся логіка зосереджена в одній кодовій базі, мікросервіси 
створені як невеликі сервіси, кожен з яких функціонує у власному ізольованому 
51 
ЧДТУ.232201.001 ПЗ 
процесі та взаємодіє з іншими за допомогою простих та швидких протоколів 
передачі даних.  
У ході розробки програмного забезпечення були встановлені конкретні 
вимоги до кожного окремого розробленого мікросервісу: мікросервіс повинен 
виконувати одну просту логічну функцію, а його оновлення має бути простим, 
без втрати попереднього функціоналу. Використання мікросервісної архітектури 
призвело до ряду переваг у порівнянні із «класичним» монолітним підходом. 
Оскільки розроблені мікросервіси є незалежними, дефекти в одному сервісі не 
впливають на інші, забезпечуючи мінімальні простої в системі. Також систему, 
побудовану за допомогою мікросервісної архітектури, легко масштабувати, 
оскільки не потрібно масштабувати всю систему, а можна розширювати лише ту 
частину функціоналу, яка вимагає найбільше обчислювальних ресурсів. 
Розділивши функціонал системи на окремі мікросервіси, легко впровадити 
використання Lambda-функцій, які є типом «безсерверних» обчислень. Це 
дозволяє виконувати програмний код без необхідності створювати сервери та 
налаштовувати їх, розробляти логіку масштабування кластера враховуючи робочі 
навантаження, підтримувати інтеграцію подій або керувати часом виконання 
функцій. Окремі частини функціоналу можна розробляти на різних мовах 
програмування, оскільки Lambda-функції можуть бути реалізовані за допомогою 
різних мов. Використання цього підходу дозволяє ефективно стягувати оплату за 
час виконання Lambda-функцій від більшості хмарних сервісів. Лямбда-функція 
завершує свій життєвий цикл та припиняє стягнення оплати у періоди простою 
системи, що відрізняється від інших підходів, що вимагають оплати за 
фіксований термін оренди обладнання. 
Для оптимізації використання обчислювальних ресурсів мікросервісів, 
представлених Lambda-функціями, та прискорення їх роботи, використовується 
віртуалізація на рівні операційної системи. Метод віртуалізації ґрунтується на 
роботі ядра операційної системи, яке підтримує кілька ізольованих примірників 
простору користувача, називаних контейнерами, замість одного. Контейнери 
гарантують повну ізольованість, що дозволяє запускати мікросервіси як повністю 
52 
ЧДТУ.232201.001 ПЗ 
незалежні компоненти, як з точки зору функціоналу, так і обчислювальних 
ресурсів. Розгортання контейнерів з мікросервісами виконується за допомогою 
сервісу оркестрації контейнерів Amazon Elastic Container Service. 
Основнім елементом структури даних у створеній системі є об'єкти. Ці 
об'єкти включають в себе структури даних, що містять інформацію про систему, 
стан загальних налаштувань системи, параметри окремих кімнат, налаштування 
пристроїв та інформацію про події від сенсорів. Об'єкт, що відображає стан 
налаштувань системи, зберігає дані про унікальний ідентифікатор системи, її 
назву та адресу помешкання. Також він включає інформацію про унікальний 
ідентифікатор стану системи, ідентифікатор клієнтського контролера, 
гіперпосилання на сервер, поточну дату та час. Об'єкт, який представляє стан 
параметрів кімнати, містить в собі дані про унікальний ідентифікатор кімнати, її 
назву, температуру, вологість, освітленість та кількість присутніх осіб. Інші 
об'єкти стосуються стану налаштувань пристроїв та інформації про події від 
сенсорів. 
Ці об'єкти даних передаються від клієнтських частин до серверної частини 
системи через Інтернет. Однією з особливостей системи "розумного" будинку є 
велика кількість подій, які надсилаються на сервер від різних клієнтів та 
потребують обробки в режимі реального часу. Для управління чергою та 
підтвердження обробки подій, а також для оптимізації використання 
обчислювальних ресурсів, система використовує сервіс черги повідомлень 
Amazon Simple Queue Service (SQS). Цей сервіс реалізує архітектурний паттерн 
брокера повідомлень у розподілених системах. Використання цього підходу 
дозволяє зберігати повідомлення в черзі для обробки під час пікових навантажень 
без потреби виділяти додаткові обчислювальні ресурси для миттєвої обробки. 
Кожна збережена подія буде оброблена під час вивільнення обчислювальних 
ресурсів у порядку черги. 
Сервіс Amazon Simple Queue Service забезпечує доставку повідомлень до 
їхніх обробників за політикою строгої одноразової обробки. Це означає, що 
кожне повідомлення доставляється лише один раз і залишається в черзі, поки 
53 
ЧДТУ.232201.001 ПЗ 
його не опрацюють та не видалить обробник. Цей підхід дозволяє точно 
визначати порядок надсилання та отримання повідомлень (рисунок 2.8).  
 
 
Рисунок 2.8 – Діаграма об'єктів оперованих даних системою «розумного» 
будинку 
 
У системі "розумного" будинку створено дві черги повідомлень: 
оперативна черга для подій, що використовуються для створення нових моделей 
штучних нейронних мереж, та черга для історичних даних, яка використовується 
для запису в базу даних для подальшого аналізу та виявлення взаємозалежностей 
між подіями за допомогою штучного інтелекту. Розподіл подій між цими чергами 
виконується за типом події за допомогою окремої AWS Lambda функції, яка 
активується тільки при отриманні нової події, не використовуючи обчислювальні 
ресурси в періоди, коли нові події відсутні. 
Структура бази даних розробленої системи "розумного" будинку 
ґрунтується на використанні структур об'єктів, які є основними елементами 
функціонування цієї системи. Дані про поточний та історичний стани клієнтських 
частин системи та налаштування під'єднаних до них приладів зберігаються у базі 
даних, що ґрунтується на об'єктно-орієнтованому підході. 
54 
ЧДТУ.232201.001 ПЗ 
Використання об'єктно-орієнтованої бази даних надає можливість 
ефективно зберігати інформацію, яка може мати різноманітну структуру полів та 
необмежені типи даних властивостей об'єктів. Це особливо актуально для даних, 
які стосуються налаштувань системи "розумного" будинку, оскільки вони можуть 
включати різноманітні типи приладів, розроблених різними виробниками, і 
використовувати різні формати даних у своїй роботі. 
Основним об'єктом в базі даних є інформація про систему, яка включає в 
себе властивості, що описують будівлі, у яких система впроваджена. Кожен 
об'єкт інформації про будівлю має асоційований масив об'єктів, які надають 
інформацію про окремі приміщення у даній будівлі. У свою чергу, кожен об'єкт 
інформації про приміщення має властивість у вигляді масиву об'єктів інформації 
про сенсори та окремий масив об'єктів, які містять інформацію про розташовані в 
цьому приміщенні прилади. 
Реалізація бази даних для зберігання інформації про стани клієнтських 
частин системи "розумного" будинку та налаштування під'єднаних до них 
приладів та сенсорів виконана за допомогою розподіленої бази даних Amazon 
DynamoDB. Amazon DynamoDB, що є базою даних пар "ключ-значення" і 
документів, може опрацьовувати операції затримки менше 10 мілісекунд, 
незалежно від масштабу використання. Ця база даних діє в декількох регіонах, 
має вбудовані засоби забезпечення безпеки, резервного копіювання та 
відновлення, а також підтримує кешування в пам'яті. 
З метою покращення швидкодії та стабільності системи "розумного" 
будинку та забезпечення клієнтським частинам швидкого доступу до операцій 
читання-запису в базі даних незалежно від їхнього місця розташування, база 
даних розгорнута та реплікується у трьох регіональних зонах AWS (Європа, 
США, Азія). Це означає, що запити від клієнтських частин системи будуть 
автоматично направлятися до географічно найближчої репліки бази даних, що 
дозволяє значно зменшити затримку операцій читання-запису в БД. Такий підхід 
також позитивно впливає на швидкодію системи під час пікових навантажень у 
55 
ЧДТУ.232201.001 ПЗ 
регіонах, оскільки Elastic Load Balancing автоматично перенаправляє запити до 
регіону з меншим навантаженням та вищою швидкістю відгуку. 
Для зберігання моделей штучних нейронних мереж, які характеризуються 
однорідною структурою даних, використовується реляційна база даних Amazon 
RDS. Цей сервіс спрощує налаштування, використання і масштабування 
реляційних баз даних у хмарному середовищі. Для забезпечення швидкодії 
операцій читання-запису та надійності зберігання даних, застосований 
аналогічний підхід розгортання реплік баз даних у різних географічних регіонах 
доступності. Сервіс Amazon RDS також дозволяє налаштовувати правила 
вертикального масштабування бази даних під час пікових навантажень, 
змінюючи обчислювальні характеристики сервера бази даних відповідно до 
поточного навантаження. 
Для захисту історичних даних, що виникають у помешканнях подій та 
зберігаються в системі за допомогою сервісу Amazon RDS, застосовується 
шифрування даних у базі даних. Шифрування застосовується до даних у всіх 
базах даних, незалежно від регіону розгортання, а також до всіх збережених 
резервних копій баз даних. Централізоване керування ключами шифрування 
відбувається за допомогою сервісу AWS Key Management Service (KMS), який 
дозволяє створювати та налаштовувати права користування окремими ключами 
для різних користувачів чи програмних сервісів. 
Перед записом або читанням даних з бази даних, шифрування виконується 
за допомогою програмного засобу AWS Encryption SDK, що інтегрований з AWS 
Key Management Service, надаючи доступ до ключів шифрування відповідно до 
налаштованих прав для конкретного користувача чи сервісу. Обчислювальні 
сервери взаємодіють з серверами баз даних через шифроване підключення за 
допомогою криптографічного протоколу Transport Layer Security (TLS). Сервіс 
Amazon RDS автоматично створює сертифікати SSL та встановлює їх на серверах 
баз даних під час їх розгортання. Ці сертифікати підписані центром сертифікації 
та містять інформацію про доменне ім'я сервера бази даних. Під час встановлення 
з'єднання сервер баз даних передає свій сертифікат обчислювальному серверу для 
56 
ЧДТУ.232201.001 ПЗ 
його ідентифікації. Узгодження доменного імені та даних, вказаних у сертифікаті, 
відбувається відповідно до протоколу RFC2459. Під час безпечного з'єднання 
дані, що передаються по ньому, шифруються і розшифровуються за допомогою 
симетричної криптосистеми до завершення з'єднання. 
Висновки до розділу 2 
Розумний будинок, заснований на хмарних технологіях та імплементації 
патерну управління станом Redux, є передовим житловим рішенням, що 
забезпечує високий рівень автоматизації та комфорту. Хмарні технології 
дозволяють ефективно збирати, зберігати та обробляти дані з різноманітних 
пристроїв у реальному часі. Використання патерну Redux в управлінні станом 
додатків у розумних будинках спрощує інтерфейс та забезпечує однозначність 
обміну даними між компонентами системи.  
Експериментальне дослідження [12] спрямоване на удосконалення 
програмного забезпечення технічних засобів IoT. Дослідження включає аналіз 
існуючих проблем, розробку нових функцій та алгоритмів для підвищення 
продуктивності та безпеки. Експерименти спрямовані на визначення 
ефективності та стабільності програмного забезпечення після внесених 
удосконалень. Теоретичне дослідження [12] включає в себе аналіз існуючих 
методів та моделей управління IoT-пристроями. Дослідження розглядає 
алгоритми та архітектурні підходи для оптимізації функціональності систем 
«розумного» будинку. Досліджується вплив використання хмарних обчислень та 
розподілених систем на підвищення ефективності та масштабованості 
програмного забезпечення для IoT.  
Синергія даних технологій дозволяє створити інтелектуальний будинок, 
який не лише реагує на потреби мешканців у реальному часі, але й забезпечує 
високий рівень безпеки та енергоефективності життєвого середовища. Такий 
підхід визначає майбутнє будівництва, об'єднуючи передові технології для 
створення розумного, зручного та ефективного простору для мешканців. 
57 
ЧДТУ.232201.001 ПЗ 
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У ПРАКТИКУ 
ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНИХ 
СИСТЕМ  
3.1 Моделювання предметної області 
3.1.1 Предметна область моделювання. Модель предметної області. 
Словник предметної області 
 Словник предменої області: 
Інтернет речей (IoT): Концепція пов'язана з підключенням фізичних 
об'єктів до Інтернету для обміну даними. 
Датчик: Пристрій, який вимірює фізичні або хімічні величини та 
перетворює їх у сигнали, які можна інтерпретувати. 
Мережа IoT: Інфраструктура, яка забезпечує зв'язок між підключеними 
пристроями. 
Мережа зв'язку: Спосіб передачі даних між пристроями в мережі IoT, такий 
як Wi-Fi, Bluetooth, Zigbee тощо. 
Хмара IoT: Хмарна інфраструктура, яка обробляє та зберігає дані, зібрані 
від підключених пристроїв. 
Аналітика даних IoT: Використання алгоритмів та аналітичних 
інструментів для винесення корисної інформації з великого обсягу даних IoT. 
Захист IoT: Заходи безпеки, що застосовуються для захисту від 
несанкціонованого доступу та атак на підключені пристрої. 
Програмне забезпечення IoT: Спеціалізоване програмне забезпечення для 
управління та контролю підключеними пристроями. 
Ідентифікація та автентифікація: Процеси визначення та підтвердження 
ідентичності підключених пристроїв. 
Для впровадження розроблених методів управління "розумним" будинком 
було обрано клієнт-серверну архітектуру програмного забезпечення. Це рішення 
спрямоване на зниження вимог до технічних характеристик обладнання, яке 
58 
ЧДТУ.232201.001 ПЗ 
встановлюється в квартирах, будинках та інших закладах, що використовують 
систему "розумного" будинку. Для цього використовуються доступні та 
економічні мікроконтролери, такі як Raspberri Pi чи Arduino. Одночасно ця 
архітектура дозволяє використовувати потужне серверне обладнання для 
основної частини обчислень. Такий підхід зменшує вартість встановлення 
системи для кінцевих користувачів та надає можливість швидкого оновлення та 
виправлення вразливостей через оновлення програмного забезпечення на сервері, 
яке негайно стає доступним для всіх клієнтів. 
3.1.2 Елементи моделювання предметної області 
Структура системи включає сенсори, побутові прилади, серверну та 
клієнтську частини. Зміни у параметрах температури та руху користувачів в 
приміщеннях призводять до генерації нових даних сенсорів, які надсилаються 
клієнтській частині для подальшого оброблення через локальну мережу LAN або 
безпровідні стандарти передачі даних, такі як ZigBee, Wi-Fi та Bluetooth. 
Серверна частина взаємодіє з клієнтською частиною, отримуючи дані про зміни 
параметрів через Інтернет, проводить навчання нових моделей штучних 
нейронних мереж, відсилає нові моделі клієнтським частинам, зберігає історичні 
дані та повідомляє користувачів системи. 
Серверна частина складається з чотирьох модулів: навчання штучної 
нейронної мережі, віддаленої бази даних, резервної віддаленої бази даних та 
сервісу оповіщень. Для реалізації програмного забезпечення серверної частини 
обрано мову програмування JavaScript. Цей вибір обумовлений можливістю 
ефективно обробляти велику кількість запитів з високою швидкістю, що є 
важливим у розробці високонавантажених систем "розумного" будинку з одним 
сервером та багатьма одночасно підключеними клієнтами, які надсилають потік 
неструктурованих даних з різноманітних сенсорів у режимі реального часу. 
Клієнтська частина отримує дані від сенсорів та побутових приладів, 
передає поточні стани системи серверній частині, отримує нові розраховані 
моделі штучної нейронної мережі від серверної частини і розраховує новий стан 
59 
ЧДТУ.232201.001 ПЗ 
налаштувань системи на основі цих моделей. Далі вона надсилає команди 
побутовим приладам для зміни їх налаштувань (рисунок 3.1). 
 
 
Рисунок 3.1 – Структура модулів розробленої системи «розумного» будинку 
 
Апаратне забезпечення клієнтської частини реалізоване на базі 
мікроконтролера Raspberry Pi. Основні фактори, які вплинули на цей вибір, 
60 
ЧДТУ.232201.001 ПЗ 
включають низьку вартість мікроконтролера, відповідність вимогам до апаратних 
характеристик клієнтського обладнання (висока швидкість процесора, достатній 
обсяг оперативної та постійної пам'яті), низьке енергоспоживання та обмежену 
теплову віддачу, що у більшості випадків не вимагає додаткового охолодження. 
Контролери можуть об'єднуватися в групи в межах окремих будівель, що 
створює логічну класифікацію генерованих даних сенсорів для подальшого 
аналізу, виявлення взаємозв'язків та взаємозалежностей між окремими 
структурами даних. Групи клієнтських контролерів з'єднуються з віддаленими 
дата-центрами через Інтернет. 
3.1.3 Робоча область моделювання 
Клієнтська частина включає апаратний модуль аналого-цифрового 
перетворення сигналів сенсорів, програмний модуль комунікації з серверною 
частиною системи, модуль керування станом системи та програмний модуль 
керування побутовими приладами. Більшість сенсорів генерують аналоговий 
сигнал, який потребує конвертації в цифровий формат для подальшого 
опрацювання системою. Модуль комунікації з сервером відправляє дані про 
поточний стан клієнтської частини системи, що використовується для навчання 
штучних нейронних мереж на серверній частині. Крім того, модуль комунікації з 
сервером отримує нові обчислені моделі штучних нейронних мереж від серверної 
частини. Отримані моделі використовуються модулем керування станом системи 
для обчислення нових налаштувань побутових приладів у приміщенні. Ці нові 
параметри надсилаються побутовим приладам за допомогою модуля керування 
побутовими приладами, які, у свою чергу, змінюють свої робочі стани відповідно 
до змін сенсорів у приміщенні. 
61 
ЧДТУ.232201.001 ПЗ 
3.2 Формування та аналіз вимог 
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні 
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні 
вимоги. 
 При розробці алгоритмів роботи системи та послідовності активностей слід 
враховувати відмінну специфіку використання розробленої системи. Важливо 
врахувати можливість використання системи в різних сферах життєдіяльності 
людини без значних змін у її основній структурі. Таким чином, перед 
розпочатком розробки алгоритмів роботи системи необхідно чітко визначити 
потенційні сфери використання системи з конкретними функціями, які вона 
повинна виконувати. Такий підхід дозволяє створити універсальну структуру з 
єдиною ядром системи, яке легко налаштовується, дозволяючи додавати чи 
видаляти окремі модулі та функції залежно від потреб конкретної сфери 
використання. 
Вимоги замовника : 
– простий та зрозумілий інтерфейс для користувача. 
– зручне керування всіма системами будинку через мобільний додаток 
або веб-інтерфейс. 
– автоматизація та сценарії: можливість легко створювати та 
налаштовувати автоматизовані сценарії для різних ситуацій. 
– віддалений доступ: здатність керувати будинком віддалено через 
Інтернет. 
– безпека: надійність системи безпеки та можливість сповіщення в разі 
виявлення надзвичайних ситуацій. 
– інтеграція з іншими продуктами: сумісність та легка інтеграція з 
іншими розумними пристроями та платформами. 
– ефективність енергоспоживання: можливість моніторингу та управління 
енергоспоживанням пристроїв. 
62 
ЧДТУ.232201.001 ПЗ 
– аналітика та звіти: збір та відображення даних щодо використання 
ресурсів та стану системи. 
– гнучкість та розширюваність: можливість легко додавати нові пристрої 
та розширювати функціонал. 
– технічна підтримка: забезпечення технічної підтримки та швидка 
відповідь на запитання користувачів. 
– конфіденційність та приватність: захист персональних даних та 
забезпечення конфіденційності інформації. 
Врахування цих вимог допоможе забезпечити, що розроблене програмне 
забезпечення відповідає потребам та очікуванням замовника. 
Вимоги розробника: 
– документація: чітка технічна документація з описом архітектури, API та 
інших ключових аспектів. 
– стандарти та протоколи: дотримання стандартів та протоколів для 
забезпечення сумісності з різними пристроями. 
– системна безпека: реалізація механізмів шифрування та захисту даних 
користувачів. 
– масштабованість: здатність системи ефективно масштабуватися для 
підтримки різної кількості пристроїв та користувачів. 
– інтеграція: можливість легко інтегрувати систему з іншими розумними 
пристроями та сервісами. 
– інструменти розробки: використання потужних інструментів розробки 
та середовищ для забезпечення ефективності роботи. 
– тестування: системне, інтеграційне та модульне тестування для гарантії 
якості ПЗ. 
– доступність та швидкодія: забезпечення високої швидкодії та 
доступності сервісів для користувачів. 
Функціональні вимоги: 
63 
ЧДТУ.232201.001 ПЗ 
– веб-інтерфейс: створення інтуїтивного та зручного веб-інтерфейсу з 
використанням сучасних технологій; можливість додавання, видалення 
та редагування пристроїв через веб-інтерфейс. 
– RESTful API: розробка RESTful API для взаємодії між веб-клієнтом та 
серверною частиною системи; можливість отримання та оновлення 
інформації про пристрої через API. 
– моніторинг та звітність: використання WebSocket або Server-Sent Events 
для миттєвого оновлення статусу пристроїв в реальному часі; зберігання 
та відстеження даних про стан пристроїв у базі даних. 
– інтеграція та сумісність: застосування протоколу MQTT для ефективної 
інтеграції з популярними IoT-платформами. 
– безпека та аутентифікація: застосування JWT для автентифікації та 
авторизації користувачів; встановлення HTTPS для шифрування 
комунікацій між веб-клієнтом та сервером. 
– автоматизація та розклади: використання Node-RED або подібного 
інструменту для конфігурації автоматизації та створення сценаріїв; 
визначення розкладів та сценаріїв використання пристроїв через веб-
інтерфейс. 
Нефункціональні вимоги: 
– швидкодія: забезпечення швидкої відповіді веб-інтерфейсу на запити 
користувача, з часом завантаження не більше 2 секунд. 
– надійність: забезпечення надійності та стабільності системи, з менше 
ніж 1% відмов при взаємодії з пристроями. 
– безпека даних: використання бібліотек для end-to-end шифрування 
даних між веб-системою та IoT-пристроями; періодична перевірка на 
вразливості та використання інструментів для аналізу коду. 
– сумісність та масштабованість: забезпечення сумісності з різними 
браузерами (Chrome, Firefox, Safari); масштабованість системи для 
підтримки не менше 1000 підключених пристроїв одночасно. 
64 
ЧДТУ.232201.001 ПЗ 
– документація та підтримка: розробка технічної документації з 
інструкціями з розгортання та використання системи; забезпечення 
онлайн-підтримки та можливості зворотнього зв'язку для користувачів. 
3.2.2 Формування вимог за допомогою діаграми прецедентів 
 
 
Рисунок 3.2 – Діаграма прецедентів роботи системи 
 
До найбільш поширених сфер використання систем "розумного" будинку 
відносяться приватні житлові будинки, лікарні, гуртожитки та склади. Основні 
функції системи "розумного" будинку для приватного житла включають 
управління медіа-розвагами, освітленням, температурним режимом, та системою 
безпеки. У лікарнях головними функціями системи "розумного" будинку є 
моніторинг життєвих показників пацієнтів, управління освітленням у палатах та 
коридорах, та регулювання температурного режиму приміщень лікарні. У 
65 
ЧДТУ.232201.001 ПЗ 
гуртожитках, ключовими вимогами для впровадження систем "розумного" 
будинку є здатність налаштовувати автоматизований моніторинг 
енергоефективності, управління освітленням, та регулювання температурного 
режиму у кімнатах. У разі використання цих систем на складських приміщеннях 
основні функції включають контроль доступу за допомогою перепусток, 
управління освітленням та регулювання температурного режиму у складських 
зонах. 
Набір основних функцій можна сформулювати, проаналізувавши потреби, 
активності та функції ключових елементів системи та користувачів. Взаємодія 
ключових елементів та функцій при виконанні завдань, що стоять перед 
системою, відображається на діаграмі прецедентів (рисунок 3.2). Користувачі 
системи мають можливість ручного надсилання команд. Крім того, рух 
користувачів у приміщеннях активує сенсори, які в свою чергу передають 
зафіксовані значення клієнтському контролеру. Контролер відповідає за 
управління станом системи в залежності від отриманих даних від сенсорів та 
результатів автоматизованого прийняття рішень щодо необхідності зміни станів 
побутових приладів. Клієнтська апаратна частина взаємодіє з сервером 
провайдера, який, у свою чергу, здійснює функцію збору історичних даних від 
сенсорів у приміщенні, а також проводить процес навчання моделей штучної 
нейронної мережі, що в подальшому використовуються клієнтською апаратною 
частиною. 
Узагальнюючи, алгоритм роботи системи виглядає наступним чином. Після 
зміни стану сенсора у приміщенні відбувається надсилання значення від датчика 
до клієнтської частини системи. Модуль клієнтської частини, відповідальний за 
аналого-цифрове перетворення значень датчиків, перетворює значення, отримані 
від сенсора, у цифровий формат. 
3.2.3 Проектування логічної структури програмного комплексу 
Також розглянемо ключові класи розробленої програмної системи через 
діаграму класів. На цій діаграмі відображено класи, їх взаємозв'язки, а також 
методи та атрибути [51]. Діаграма класів системи представлена на рисунку 3.6. 
66 
ЧДТУ.232201.001 ПЗ 
На цій діаграмі представлено п'ять основних класів із різних пакетів, а також 
основні методи, які визначають функціональність кожного класу. 
Класи програмної реалізації системи відповідають основним модулям та 
компонентам як клієнтської, так і серверної частини. У складі програмних класів 
клієнтської частини включаються: клас, який відповідає за збір даних від 
сенсорів; клас, який відповідає за конвертацію сигналів сенсорів та команд для 
побутових приладів; клас головного контролера; клас, що реалізує 
автоматизований процес прийняття рішень; клас управління базою даних; клас, 
який відповідає за комунікацію з серверною частиною. 
У програмні класи серверної частини входять: клас, що відповідає за 
аналітику даних; клас для взаємодії з клієнтською частиною; клас головного 
контролера серверної частини; клас управління базами даних; клас емуляції 
роботи моделей штучних нейронних мереж; клас, який відповідає за тренування 
штучних нейронних мереж. 
3.2.3.1 Діаграми класів 
На рисунку 3.3 представлена діаграма класів розробленої системи 
"розумного" будинку, включаючи як клієнтську, так і серверну частину. 
 
 
Рисунок 3.3 – Діаграма класів розробленої системи «розумного» будинку 
67 
ЧДТУ.232201.001 ПЗ 
3.2.3.2 Діаграми пакетів 
Існуючі пакети в розробленій програмній системі приведені на рисунку 3.4. 
 
 
Рисунок 3.4 – Пакети програмної системи 
 
У програмній системі виділяються чотири пакети: gui, який відповідає за 
користувацький інтерфейс; controller, що забезпечує зв'язок між моделлю та 
користувацьким інтерфейсом; модуль modeling, що включає реалізації моделей 
класифікації, і processing, який вміщує реалізації сегментації та формування 
вектору ознак. 
3.2.4 Архітектурне проектування 
Система, яку ми розробляли, складається з внутрішньо- та зовнішньо-
системних компонентів. Внутрішньосистемні компоненти включають в себе 
модулі, що стосуються клієнтської та серверної частин. До клієнтської частини 
входять модуль збору параметрів сенсорів, модуль перетворення параметрів, 
модуль головного контроллера, модель автоматизованого прийняття рішень, 
модуль збереження стану компонентів системи, модуль управління базою даних, 
модель комунікації з віддаленим сервером і модуль управління приладами. 
68 
ЧДТУ.232201.001 ПЗ 
3.2.4.1 Діаграма компонентів 
 
 
Рисунок 3.5 – Діаграма компонент розробленої системи «розумного» будинку 
 
Діаграма компонент розробленої системи «розумного» будинку зображена 
на рисунку 3.5. 
До серверної частини входять модуль аналітики збережених даних, модель 
комунікації з клієнтськими частинами, модуль головного контроллера, модуль 
збереження даних від клієнтських контроллерів, модуль тестування роботи 
створених моделей, модуль управління базою даних і модуль навчання моделей 
штучних нейронних мереж. 
69 
ЧДТУ.232201.001 ПЗ 
Зовнішньосистемні модулі включають віддалені бази даних, мережевий 
шлюз, хостинг інтерфейсу управління сервером, модуль нотифікації 
користувачів, сенсори та прилади. На діаграмі компонентів "розумного" будинку 
зображено взаємодію цих компонентів. Користувач активує сенсори, що 
викликають ланцюг подій у системі, включаючи зміну налаштувань, комунікацію 
з приладами та повідомлення користувачам. Система також використовує 
навчання штучних нейронних мереж для оптимізації свого функціонування. 
Розгортання розробленої системи для розумного будинку відбувається 
шляхом використання практик безперервної інтеграції та безперервної доставки 
програмного забезпечення. Безперервна інтеграція дозволяє регулярно 
об'єднувати зміни в програмному коді у центральному репозиторії, після чого 
автоматично проводиться збірка програмних пакетів, автоматизоване тестування 
і запуск на виконання. Концепція безперервної інтеграції, яка найчастіше 
використовується на етапі збірки програмних пакетів чи інтеграції процесу 
розгортання програмного забезпечення, включає як автоматизацію (наприклад, 
сервіси безперервної інтеграції або збірки), так і культуру розробки (наприклад, 
підтримку частої інтеграції ПЗ). Основною перевагою впровадження практики 
безперервної інтеграції є можливість швидко виявляти і виправляти помилки у 
функціоналі системи "розумного" будинку, покращувати якість програмного 
забезпечення і зменшувати часові витрати на перевірку та випуск нових 
оновлень. Впровадження практики безперервної інтеграції у хмарному 
середовищі реалізовано за допомогою сервісу AWS CodeBuild. Після внесення 
змін у програмне забезпечення в репозиторії кодової бази системи за допомогою 
системи контролю версій Git, сервіс безперервної інтеграції реагує на ці зміни, 
автоматично запускаючи процес збірки програмних пакетів з останніми 
внесеними змінами. Після успішного завершення етапу збірки, сервіс 
безперервної інтеграції запускає автоматизоване тестування нового програмного 
пакету на відповідність функціональним вимогам. Результатом цього етапу є звіт 
про успішність пройденого тестування та готовий пакет програмного 
забезпечення, або звіт, що містить опис знайдених помилок та вразливостей. 
70 
ЧДТУ.232201.001 ПЗ 
Практика безперервної доставки дозволяє автоматизувати процеси збірки 
програмних пакетів, автоматизованого тестування та готування до остаточного 
випуску програмного забезпечення при будь-яких змінах у програмному коді. 
Безперервна доставка є ключовим принципом сучасної розробки додатків, 
розширюючи практику безперервної інтеграції через автоматичне розгортання у 
тестовому або робочому середовищі всіх змін коду після стадії збірки 
програмних пакетів. Цей підхід дозволяє мати готовий до розгортання екземпляр 
програмного забезпечення серверної частини системи "розумного" будинку, який 
успішно пройшов стандартизовану процедуру тестування. 
Безсерверна доставка для системи "розумного" будинку реалізована за 
допомогою сервісу AWS CodePipeline. Цей сервіс дозволяє отримувати 
результати успішної збірки програмних пакетів від AWS CodeBuild та 
автоматично розгортати їх на тестовому сервері для подальшого ручного 
тестування системи з використанням AWS CodeDeploy. Після успішного ручного 
тестування останньої збірки і підтвердження її відповідності функціональним та 
нефункціональним вимогам, через AWS CodePipeline налаштовуються правила 
автоматичного розгортання програмних пакетів на сервера, доступні кінцевим 
користувачам та клієнтським частинам системи. 
3.2.4.2 Розгортання програмної системи на апаратних засобах. Діаграма 
розгортання 
Розгортання розробленої системи розумного будинку включає п'ять логічно 
групованих пакетів. Перший пакет включає розгортання веб-сервера, що містить 
модуль візуального представлення інтерфейсу користувача. Пакет сервісу 
нотифікації включає модулі повідомлень за допомогою електронних листів, SMS 
та push-нотифікації. Пакет сервісу машинного навчання включає модуль 
тренування моделей штучної нейронної мережі та модуль емуляції їхньої роботи. 
Пакет серверу бази даних включає модулі основної та резервної баз даних. Пакет 
сервісу логіки включає модуль комунікації з клієнтськими частинами, модуль 
аналізу даних та модуль головного контроллера. Діаграма розгортання системи 
"розумного" будинку представлена на рисунку 3.6. 
71 
ЧДТУ.232201.001 ПЗ 
 
 
Рисунок 3.6 – Діаграма розгортання системи «розумного» будинку 
 
Під час початкової реалізації системи був використаний метод емуляції 
поведінки користувачів та їх впливу на підсистему керування освітлювальними 
приладами. Під час руху людини в приміщенні датчик руху передає результати 
клієнтському контролеру. Заснований на внутрішній логіці, контролер висилає 
команду для увімкнення освітлювального приладу в приміщенні та оновлює 
параметри (останній час визначення руху та режим освітлення) усім іншим 
контролерам, підключеним до системи, для можливості відновлення попередніх 
параметрів у разі відмови контролера під час тимчасового відключення живлення 
або при перебоях в роботі електромережі. Проте, під час розширення обсягу 
застосування системи та додавання нових приміщень для управління, виявилось, 
що цей підхід є складним у використанні та проявляє тенденцію до сповільнення 
роботи системи при збільшенні кількості нових датчиків та побутових приладів, 
72 
ЧДТУ.232201.001 ПЗ 
які підключаються до системи. Можливості масштабування та подальшого 
розвитку системи за використаного на початковому етапі підходу взаємодії 
компонентів (датчики, прилади) обмежуються заплутаністю взаємозв'язків між 
компонентами для зміни стану системи та повідомлення всіх інших компонентів 
про оновлення стану. При безпосередній взаємодії датчиків руху, датчиків 
освітлення та освітлювальних приладів. Аналіз продуктивності розглянутої 
системи "розумного" будинку базувався на випадковій вибірці змін стану 
системи, які мали збережені часові мітки на кожному етапі отримання та 
надсилання команд між компонентами системи. Перша вибірка включає множину 
з 30 випадково обраних записів змін стану при використанні підходу 
безпосередньої взаємодії між компонентами системи. Друга вибірка містить 30 
випадково обраних записів змін стану при впровадженні архітектурного шаблону 
Redux. Порівняльний аналіз отриманих результатів та показників свідчить про 
переваги використання архітектурного шаблону Redux у сфері систем 
"розумного" будинку. Серед таких переваг варто відзначити зменшення кількості 
запитів між різними компонентами системи, що призводить до підвищення 
швидкодії та загальної надійності системи. Також завдяки зменшенню кількості 
взаємозв'язків між компонентами системи вдається прискорити зміну стану 
системи. Впровадження архітектурного шаблону Redux дозволило зменшити 
кількість запитів між компонентами системи з 120 до 60, що представляє 50% 
зменшення порівняно з початковим значенням до модернізації системи. 
Швидкість оновлення загального стану системи зросла на 0,396 секунди, що 
відзначає 46% прискорення роботи системи в порівнянні з попередніми вимірами 
до її модернізації. 
3.2.5 Моделювання поведінки системи 
3.2.5.1 Діаграма діяльності 
Клієнтська частина системи може знаходитися у шести можливих станах, 
включаючи режим очікування, процес аналого-цифрового перетворення сигналу 
сенсора, калькуляцію нового стану системи, відправку команд для зміни 
73 
ЧДТУ.232201.001 ПЗ 
налаштувань приладів, очікування підтвердження зміни налаштувань приладів та 
сповіщення користувача про зміну налаштувань приладів. Графічне 
представлення переходів між цими станами наведено на рисунку 3.7. 
 
 
Рисунок 3.7 – Діаграма діяльності системи 
 
Взаємодія між користувачами, побутовими приладами та чотирма вузлами 
системи, такими як сенсори, клієнтська частина, серверна частина та база даних, є 
основним елементом функціональності. Послідовності виконання завдань та 
активностей в рамках роботи системи представлені на наступних діаграмах. 
Основними структурами даних якими оперує розроблена система є об'єкти. 
Такими об'єктами є структури даних інформації про систему, стан загальних 
налаштувань системи, стан параметрів окремих кімнат, стан налаштувань 
приладів та інформація події від сенсорів. Об'єкт стану налаштувань системи 
зберігає дані про унікальний ідентифікатор системи, назву системи та адресу 
помешкання у якому система запроваджена. Об'єкт стану налаштувань системи 
містить інформацію про унікальний ідентифікатор стану системи, унікальний 
ідентифікатор клієнтського контроллера, гіперпосилання шляху серверу, поточну 
дату та час. Об'єкт стану 151 параметрів кімнати містить інформацію про 
74 
ЧДТУ.232201.001 ПЗ 
унікальний ідентифікатор кімнати, назви кімнати, температуру у кімнаті, 
показник вологості у кімнаті, показник освітленості кімнати та кількість 
присутніх у кімнаті людей.  
3.2.5.2 Діаграма послідовності  
Діаграма послідовності роботи системи зображена на рисунку 3.8. 
 
 
Рисунок 3.8 – Діаграма послідовності роботи системи 
 
3.2.5.3 Діаграма комунікації 
 
 
Рисунок 3.9 – Діаграма комунікацій компонентів розробленої системи 
75 
ЧДТУ.232201.001 ПЗ 
Діаграма комунікацій компонентів розробленої системи зображена на 
рисунку 3.9 
Класи програмної реалізації системи відповідають головним модулям та 
компонентам клієнтської та серверної частини. Програмними класами клієнтської 
частини є: клас відповідальний за збір даних від сенсорів, клас відповідальний за 
конвертацію сигналів сенсорів та конвертацію команд для побутових приладів, 
клас головного контроллера, клас відповідальний за реалізацію автоматизованого 
процесу прийняття рішень, клас управління базою даних, клас відповідальний за 
комунікацію серверної частини.\ 
3.2.5.4 Діаграма скінченного автомату 
 
 
Рисунок 3.10 – Діаграма скінченного автомату  
76 
ЧДТУ.232201.001 ПЗ 
Діаграма скінченного автомату зображена на рисунку 3.10 
Об'єкт стану налаштувань приладу містить інформацію про унікальний 
ідентифікатор приладу, стан увімкнення/вимкнення, інформацію про режим 
роботи, показник енергоспоживання, час безперервної роботи приладу. Об'єкт 
згенерованої події сенсору містить інформацію про унікальний ідентифікатор 
події, тип події, цифрове значення сенсору, дата виникнення події та час 
виникнення події. 
Висновки до розділу 3 
Побудована веб-система керування IoT-пристроями визначається низкою 
ключових характеристик, спрямованих на створення ефективного та інтуїтивного 
інтерфейсу для управління підключеними пристроями через веб. Розроблений 
централізований веб-інтерфейс дозволяє користувачам легко та ефективно 
взаємодіяти з різноманітними IoT-пристроями, забезпечуючи однаковий рівень 
зручності управління з будь-якого пристрою або місця. 
Система забезпечує плавну інтеграцію з різноманітними IoT-пристроями та 
протоколами, забезпечуючи високу ступінь сумісності та легкість розширення 
системи новими пристроями. 
Реалізовані механізми шифрування та аутентифікації гарантують захист від 
несанкціонованого доступу, а також забезпечують конфіденційність особистої 
інформації користувачів. Включення системи аналітики та моніторингу дозволяє 
отримувати дані про стан та функціонування пристроїв в реальному часі, що 
сприяє ефективній оптимізації їх роботи та передбаченню можливих проблем. 
Система ретельно спроектована з огляду на використання користувачів, що 
включає інтуїтивний інтерфейс та можливість персоналізації відповідно до 
унікальних потреб користувачів. Забезпечена можливість масштабування 
системи для оптимальної обробки зростаючої кількості підключених пристроїв та 
гнучкість у впровадженні нових функцій та оновлень. 
77 
ЧДТУ.232201.001 ПЗ 
Дана готова система орієнтована на створення інтелектуального житлового 
середовища, де управління IoT-пристроями відбувається ефективно, безпечно та 
інтуїтивно зрозуміло для кожного користувача. 
78 
ЧДТУ.232201.001 ПЗ 
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО 
ЗАБЕЗПЕЧЕННЯ 
4.1.Розробка програмного комплексу 
4.1.1 Обґрунтування вибору засобів реалізації 
JavaScript, часто позначений як JS, є програмувальною мовою, що відповідає 
специфікації ECMAScript. Високорівневий та мультипарадигмовий, JavaScript 
часто компілюється "на льоту". Він володіє динамічною типізацією, прототипно-
об'єктною орієнтацією та функціями першого класу. JavaScript є ключовою 
технологією у всесвітній мережі поряд з HTML та CSS. 
JavaScript використовується для створення інтерактивних веб-сторінок та є 
невід'ємною частиною веб-додатків. Більшість веб-сайтів використовують 
JavaScript для клієнтської поведінки, і всі основні веб-браузери включають 
спеціальні механізми для його виконання [2]. Найпоширеніші середовища 
розробки (IDE) для JavaScript: Webstorm, Visual Studio Code. 
Початково JavaScript був розроблений для надання життя веб-сторінкам та 
надання їм динаміки. Програми, написані на JavaScript, зазвичай називають 
скриптами і вбудовуються в HTML, виконуючись при завантаженні сторінки в 
браузері без потреби у компіляції або спеціальній підготовці. Це відрізняє 
JavaScript від мови програмування Java. 
JavaScript, подібно до інших високорівневих мов, не надає розробникам 
доступ до низькорівневого коду та управління пам'яттю, що сприяє зменшенню 
можливостей виникнення помилок. Сьогодні JavaScript може виконуватися не 
лише в браузері, але і на сервері чи будь-якому іншому пристрої, що має 
відповідний "рушій" JavaScript. У всіх сучасних браузерах вбудований рушій, 
відомий як "віртуальна машина JavaScript". Для розробки серверної частини 
додатків на JavaScript розробники часто використовують платформу Node.js. 
Переваги JavaScript: 
79 
ЧДТУ.232201.001 ПЗ 
– швидкість: JavaScript виконується безпосередньо в браузері клієнта, що 
забезпечує його високу швидкість. До тих пір, поки користувач не 
надсилає додаткових запитів на сервер, що викликає запуск, JavaScript 
не впливає на продуктивність. 
– простота: Синтаксис JavaScript, створений за впливом мови Java, легко 
вивчається, на відміну від інших популярних мов, таких як C та C++. 
– популярність: JavaScript широко використовується в Інтернеті та з 
часом набув популярності в області серверного програмування завдяки 
Node.js. Існує велика кількість ресурсів для вивчення JavaScript. 
– взаємодія: На відміну від PHP та інших скриптових мов, JavaScript може 
бути вбудований та виконуватися на будь-якій веб-сторінці. Його також 
можна використовувати в різних системах через підтримку інших мов, 
таких як Pearl та PHP. 
– завантаження сервера: JavaScript є клієнтською надбудовою, що 
зменшує навантаження на сервер, особливо для простих додатків, які 
можна реалізувати без сервера. 
– універсальність: JavaScript може бути використаний для створення 
серверів за допомогою Node.js. За його допомогою можна розробляти 
програми, використовуючи лише JavaScript, включаючи сервер на 
Express, використання бази даних MongoDB та написання інтерфейсу. 
Недоліки JavaScript: 
– захист на стороні клієнта: Оскільки код JavaScript виконується на 
стороні клієнта, помилки та уразливості можуть бути використані 
зловмисниками для здійснення атак. Це призводить до відключення 
виконання JavaScript сценаріїв в браузерах деякими користувачами. 
– підтримка браузера: Хоча скрипти завжди мають однаковий результат 
при виконанні на сервері, різні браузери іноді розуміють JavaScript по-
різному. Сучасні різниці мінімальні, але тестування скриптів у всіх 
основних браузерах є важливим етапом. 
 
80 
ЧДТУ.232201.001 ПЗ 
4.1.2 Опис структурної (функціональної) схеми 
Структура бази даних системи "розумного" будинку побудована на основі 
структур об'єктів, якими оперує сама система. Інформація про поточні та 
історичні стани клієнтських частин системи та налаштування під'єднаних до них 
приладів зберігається у базі даних, яка використовує об'єктно-орієнтований 
підхід. Використання такої бази даних дозволяє зберігати інформацію, яка не має 
сталої структури полів та визначених типів даних властивостей об'єктів, що є 
необхідним для даних, пов'язаних з налаштуваннями системи "розумного" 
будинку. Система враховує налаштування різних типів приладів від різних 
виробників, що використовують різні формати даних у роботі своїх продуктів. 
Використання декількох реплік бази даних дозволяє надійне зберігання 
інформації за рахунок можливості швидкого відновлення бази даних після 
апаратного збою на основі збережених баз даних з реплік розташованих у інших 
регіонах. Однорідна структура даних, що характерна для зберігання моделей 
штучних нейронних мереж дає змогу використати реляційну базу даних, яка 
зберігає дані у вигляді таблиць з чітко визначеними полями та дозволяє швидко 
опрацьовувати запити на читання великої кількості інформації з однорідною 
схемою даних. Для реалізації реляційної бази даних у розробленій системі 
використаний сервіс Amazon RDS, який спрощує налаштування, використання і 
масштабування реляційних баз даних у хмарі. Для підвищення швидкодії 
операцій читання-запису та надійності зберігання даних, використаний 
аналогічний підхід розгортання реплік баз даних у декількох географічних 
регіонах доступності. Також, за допомогою функціоналу, що надається сервісом 
Amazon RDS налаштовані правила вертикального масштабування бази даних під 
час пікових навантажень, тобто обчислювальні характеристики сервера бази 
даних (характеристики процесора та об'єму сховища даних) автоматично 
змінюються відповідно до поточного навантаження на БД. 
4.1.3 Опис логічної схеми системи 
81 
ЧДТУ.232201.001 ПЗ 
При початковій реалізації системи був використаний метод емуляції 
поведінки користувачів системи та її вплив на роботу підсистеми керування 
освітлювальними приладами. Під час руху людини у приміщенні, давач руху 
надсилає результат клієнтському контролеру. На основі внутрішньої логіки, 
контролер надсилає команду для увімкнення освітлювального приладу 
розташованому у приміщенні, а також надсилає оновлені параметри у 
приміщення (останній час визначення руху та режим роботи освітлення) усім 
іншим контролерам, що під’єднані до системи для можливості відновлення 
попередніх параметрів у разі збою роботи контролера при тимчасовому 
відключенні живлення у разі перебоїв роботи електромережі.  
Під час розширення емуляції сфер використання розробленої системи та 
додавання нових приміщень у керування системою, під час практичного 
використання цей підхід виявився складномасштбованим та з явною тенденцією 
на зниження швидкодії роботи системи при збільшенні кількості нових давачів та 
побутових приладів під’єднаних до системи. Можливості масштабування та 
подальшого розвитку системи при використаному на першому етапі розробки 
підході взаємодії компонентів (давачі, прилади) системи обмежуються 
заплутаністю взаємозв’язків між компонентами для зміни станів системи та 
повідомлення усіх решти компонентів про оновлення стану.  
Аналіз швидкодії роботи розглянутої системи «розумного» будинку 
відбувався на основі випадково вибраної множини змін станів системи зі 
збереженими часовими мітками на кожному етапі отримання та надсилання 
команд між компонентами системи. Перша вибірка містить множину з 30 
випадково відібраних записів змін станів при використанні підходу 
безпосередньої взаємодії між компонентами системи. Друга вибірка містить 
множину з 30 випадково відібраних записів змін станів при запровадженні 
архітектурного шаблону Redux. 
4.1.4 Розробка бази даних  
Головний об'єкт бази даних, що містить інформацію про систему, включає в 
себе властивість об'єкта, яка надає інформацію про будівлі, в яких система 
82 
ЧДТУ.232201.001 ПЗ 
впроваджена. Кожен об'єкт інформації про будівлю має властивість у вигляді 
масиву об'єктів, які містять інформацію про приміщення у даній будівлі. Де 
кожен об'єкт інформації про приміщення включає в себе масив об'єктів з 
інформацією про сенсори та масив об'єктів з інформацією про прилади, 
розташовані у відповідних приміщеннях (рисунок 4.1). 
 
 
Рисунок 4.1 – Діаграма структури бази даних розробленої системи «розумного» 
будинку 
 
Реалізація документоорієнтованої бази даних для зберігання інформації про 
стани клієнтських частин системи «розумного» будинку та інформації про 
налаштування під'єднаних до них приладів і сенсорів реалізоване за допомогою 
розподіленої бази даних Amazon DynamoDB. Amazon DynamoDB – це база даних 
пар «ключ-значення» і документів, яка забезпечує затримку менше 10 мілісекунд 
при роботі у будь-якому масштабі. Дана база даних працює в декількох регіонах з 
кількома активними серверами і має вбудовані засоби забезпечення безпеки, 
резервного копіювання та відновлення, а також кешування в пам'яті. Для 
підвищення швидкодії і стабільності роботи розробленої системи та забезпечення 
клієнтським частинам швидкого 155 доступу до операцій читання-запису 
83 
ЧДТУ.232201.001 ПЗ 
інформації бази даних незалежно від географічного розташування розгорнутої 
клієнтської частини системи «розумного» будинку, база даних реплікується та 
розгортається у трьох регіональних зонах сервісів AWS (Європа, США, Азія).  
4.1.5 Розробка інтерфесу користувача 
Таким чином запити від клієнтських частин системи будуть за допомогою 
сервісу Elastic Load Balancing автоматично перенаправлятися до географічно 
найближчої репліки бази даних, тим самим суттєво знижуючи час затримки 
опрацій читання-запису інформації у БД. Одночасно даний підхід позитивно 
впливає на швидкодію системи під час пікових навантажень у окремому регіоні, 
коли Elastic Load Balancing автоматично перенаправлятиме запити до бази даних 
з меншим навантаженням на обчислювальні ресурси та більшою швидкістю 
віддачі результату, що розташована у іншому регіоні.  
4.1.6 Опис розробки програмних компонентів 
При безпосередній взаємодії давачів руху, давачів освітлення та 
освітлювальних приладів, діаграма взаємозв’язків між усіма давачами та 
приладами у розробленій системі має наступний вигляд. Для вирішення 
проблеми складності логіки комунікації між компонентами системи, був 
використаний архітектурний шаблон Redux, при запроваджені якого давачі та 
прилади не взаємодіють безпосередньо між собою. Всі давачі надсилають події 
зміни своїх значень редюсеру, який у свою чергу змінює стан системи у сховищі 
даних відповідно до розробленої внутрішньої логіки реагування на конкретну 
подію. У свою чергу прилади підписані на «прослуховування» змін у сховищі 
даних змінюють власні налаштування роботи при виникненні зміни параметрів 
стану системи. Взаємозв’язки між усіма давачами та приладами у розробленій 
системі з використанням архітектурного шаблону Redux мають наступний вигляд 
(рисунок 4.2). 
84 
ЧДТУ.232201.001 ПЗ 
 
 
Рисунок 4.2 – Діаграмма зв’язків при використанні архітектурного шаблону 
Redux 
 
4.2 Тестування системи 
Тестування інформаційної системи це етап, що проводиться для 
покращення якості програмного продукту. Для даної системи необхідно провести 
4 типи тестування:  
– функціональне тестування;  
– модульне тестування;  
– тестування обсягом;  
– навантажувальне тестування;  
Функціональне тестування 
Функціональне тестування – це проходження всіх функціональних вимог, 
що ставились перед системою та пошук розходжень між наявним функціоналом 
та бажаним. Модульне тестування – це тестування методів системи. Для 
модульного тестування буде використовуватись система PHPUnit – це система 
для юнитестування додатків, написана на мові PHP. Під "юніт" розуміються 
невеликі блоки коду, наприклад окремі методи класу. Для тестування об’ємів 
буде використовуватись програмний інтерфейс до бази даних MySQL. 
Навантажувальне тестування буде проводитись за допомогою застосунку Apache 
85 
ЧДТУ.232201.001 ПЗ 
JMeter. Тестування буде проводитись на комп’ютері під управлінням ОС 
Windows 10 64х з процессором Intel Pentium 2117U із частотою 1,8 ГГц та 
оперативною пам’яттю у 8 Гбайт. На якість навантажувального тестування буде 
впливати обчислювальна потужність машини, на якій розгорнуто веб-сервер. На 
якість розроблених модульних тестів впливає складність на розміри методів, до 
яких розробляютсья тести. Чим більше логіки реалізує метод, чим більше 
сторонніх сутностей він використовує, тим складніше розробити повні модульні 
тести. 
Для проведення функціонального тестування треба розробити спеціальні 
тест-кейси. Для цього необхідно створити список з роз’ясненням кожного 
тесткейсу. Список має таку структуру: ідентифікатор – номер функціональної 
вимоги – опис тесту – передумови – що треба зробити – що повинно відбутись. 
Таблиця 4.1 
Результат функціонального тестування  
Тестовий сценарій Опис тесту Результат 
Підключення Впевнитися, що пристрій може бути успішно 
пристрою до підключений до системи IoT за допомогою Успішно 
системи визначених протоколів та інтерфейсів. 
Відправлення та Перевірити можливість передачі та отримання 
Успішно 
отримання даних даних між пристроями та сервером системи IoT. 
Впевнитися, що користувач може успішно 
Управління 
керувати пристроями через веб-інтерфейс або Успішно 
пристроями 
мобільний додаток. 
Перевірити, чи можливо в реальному часі 
Моніторинг стану 
відстежувати стан та параметри пристроїв через Успішно 
пристроїв 
систему моніторингу. 
Переконатися, що система виконує заплановані 
Автоматизація та 
автоматизовані дії та розклади відповідно до Успішно 
розклади 
встановлених параметрів. 
Перевірити заходи безпеки, включаючи 
Безпека даних шифрування даних та захист від Успішно 
несанкціонованого доступу. 
Переконатися, що програмне забезпечення є 
Сумісність з різними 
сумісним із різними пристроями та операційними Успішно 
платформами 
системами. 
Провести тести на виявлення та коректне 
Реакція на помилки врегулювання системою помилок, включаючи Успішно 
відмови та збої 
86 
ЧДТУ.232201.001 ПЗ 
За результатами функціонального тестування можна зазначити, що 
функціональні тести були виконані та відповідають заданим вимогами.  
4.2.1 Модульне тестування 
Проведення модульного тестування Для проведення модульних тестів 
скористаємось бібліотекою phpunit.  
Загальне покриття коду складає 45% покритих строчок. Дані про покриття 
вихідного коду модульними тестами здобуто за допомогою утиліти coverage. 
Дана утиліта надає значення покриття програмного коду модульними тестами за 
файлами з вихідним кодом. Настільки малий відсоток покриття тестами 
пояснюється тим фактом, що в фреймворку Laravel значна кількість коду є 
необхідним для праці системи. Ці рядки не несуть бізнес-логіки та не повинні 
бути покритими тестами. 
 
 
Рисунок 4.3 – Покриття коду модульними тестами 
 
Для демонстрації тестів візьмемо один з тест-кейсів та опишемо принцип 
його роботи. Прикладом буде тест-кейс для класів моделей, які відображають 
сутності бази даних. 
class UpdateThreadsTest extends TestCase 
{ 
87 
ЧДТУ.232201.001 ПЗ 
use RefreshDatabase; 
public function setUp() 
 { 
parent::setUp(); 
$this->withExceptionHandling(); 
$this->signIn(); 
 } 
/** @test */ 
function unauthorized_users_may_not_update_threads() 
 { 
$thread = create('App\Thread', ['user_id' => create('App\User')->id]); 
$this->patch($thread->path(), [])->assertStatus(403); 
 } 
/** @test */ 
function a_thread_requires_a_title_and_body_to_be_updated() 
 { 
$thread = create('App\Thread', ['user_id' => auth()->id()]); 
$this->patch($thread->path(), [ 
'title' =>'Changed' 
])->assertSessionHasErrors('body'); 
$this->patch($thread->path(), [ 
'body' =>'Changed' 
])->assertSessionHasErrors('title'); 
 } 
/** @test */ 
function a_thread_can_be_updated_by_its_creator() 
 { 
$thread = create('App\Thread', ['user_id' => auth()->id()]); 
$this->patch($thread->path(), [ 
'title' =>'Changed', 
88 
ЧДТУ.232201.001 ПЗ 
'body' =>'Changed body.' 
]); 
tap($thread->fresh(), function ($thread) { 
$this->assertEquals('Changed', $thread->title); 
$this->assertEquals('Changed body.', $thread->body); 
 }); 
 } 
} 
Таким чином було проведено тестування більшої частини класів проекту, 
що піддається написанню модульних тестів. Класи, що надаються фреймворком, 
не були протестовані, так як це було б надмірно. Важливим моментом при 
проведенні модульного тестування є контролювання надмірності складання 
тестів, особливо при використанні фреймворку: більшість інструментів вже 
створені на протестовані, тому доцільно складати модульні тести лише для 
створених під час розробки нових полів та поведінок. 
Таблиця 4.2 
Результат модульного тестування  
Модуль тесту Опис тесту Результат  
(1-10) 
Модуль 
Перевірити, чи вдало встановлюється з'єднання з 
підключення до 9.5 
базою даних та чи можливий доступ до неї з модуля. 
бази даних 
Модуль Перевірити правильність обробки вхідних даних та 
8.5 
обробки даних вивід очікуваних результатів. 
Модуль 
Перевірити, чи коректно працює модуль управління 
управління 9.0 
пристроями та чи вони взаємодіють правильно. 
пристроями 
Модуль 
Перевірити, чи вірно визначається стан пристроїв та 
моніторингу 8.8 
чи відповідає вихід очікуваним значенням. 
стану 
Модуль Перевірити, чи коректно виконуються автоматизовані 
9.2 
автоматизації завдання згідно з планом та розкладом. 
Перевірити, чи ефективно використовуються методи 
Модуль безпеки 
шифрування та захисту для забезпечення безпеки 9.3 
даних 
даних. 
Модуль Перевірити, чи взаємодіє модуль коректно з іншими 
8.9 
сумісності модулями та системами без конфліктів. 
89 
ЧДТУ.232201.001 ПЗ 
 
У таблиці числові значення відображають оцінку кожного тесту від 1 до 10, 
де 10 - це ідеальний результат, а 1 - найнижчий. Ці оцінки відображають 
загальний успіх кожного модулю в рамках його функціональності та надійності. 
4.2.2 Інтеграційне тестування 
Інтеграційне тестування як вид вебтестування використовується для 
перевірки взаємодії між окремими модулями систем, а також перевірки цілісної 
системи як результату взаємодії окремих модулів. 
При інтеграційному тестуванні існує декілька підходів: 
– знизу вверх. Спочатку збираються компоненти та/або модулі самих 
низьких рівнів, поступово піднімаючись по ієрархії, доходячи до цілої системи. 
Для використання цього підходу необхідно, щоб всі компоненти були реалізовані 
і готові до тестування; 
– зверху вниз. Цей підхід починає тестування з самого високого рівня 
системи і йде вниз до самих мінімальних компонентів. У процесі тестування цим 
методом у кожен компонент вищого рівня замість підстановки справжніх 
компонентів нижчих рівнів підставляються їх заглушки, що дозволяє тестувати 
логіку тільки поточного компонента, не спираючись на його залежності; 
– великий вибух. Усі компоненти збираються в єдину повну систему і 
тестуються на функціях системи [40]. 
Схема процесу реалізації інтеграційного тестування наведена на 
рисунку 4.4. 
 
90 
ЧДТУ.232201.001 ПЗ 
 
Рисунок 4.4 – Схема процесу реалізації інтеграційного тестування 
 
Для прикладу реалізації інтеграційного тестування розглянемо скрипт, 
написаний на мові програмування JavaScript та реалізований за допомогою 
фреймворку Cypress, який перевіряє те, що при натисканні на поле для вводу 
тексту з’являється випадаючий список елементів, кожен з яких може бути 
результатом пошуку по введеному у поле тексту. 
Скрипт інтеграційного тестування за допомогою програмного коду: 
function checkDropdownMenuVisible () { 
cy.get(this.input).click(); 
cy.get(this.dropdownMenu).should(‘be.visible’} 
} 
За допомогою даного скрипту реалізується інтеграційне тестування 
випадаючого списку у поле для введення тексту. 
 
 
91 
ЧДТУ.232201.001 ПЗ 
Таблиця 4.4 
Результат інтенраційного тестування  
Результат 
Сценарій 
Опис тесту (за шкалою 
тесту 
від 1 до 10) 
Перевірка коректності взаємодії системи з базою 
Інтеграція з 
даних та правильності зберігання та отримання 9.0 
базою даних 
даних. 
Інтеграція 
Перевірка правильності передачі даних між 
модулів 
модулями обробки та виведення очікуваних 8.5 
обробки 
результатів. 
даних 
Інтеграція Тестування взаємодії модуля управління 
управління пристроями з іншими модулями та правильність 9.2 
пристроями виконання команд. 
Інтеграція Перевірка вірності взаємодії модуля моніторингу 
моніторингу стану з іншими частинами системи та коректність 8.8 
стану відображення даних. 
Перевірка синхронізації та взаємодії модуля 
Інтеграція 
автоматизації з різними функціональними 9.1 
автоматизації 
частинами системи. 
Перевірка ефективності та коректності 
Інтеграція 
застосування методів шифрування та захисту 9.3 
безпеки даних 
даних у всій системі. 
Перевірка сумісності системи з різними 
Інтеграція 
пристроями та забезпечення взаємодії без 9.0 
сумісності 
конфліктів. 
 
4.2.3 Системне тестування 
Для тестування роботи з базою даних треба провести тестування 
навантаженням. Для цього база даних заповнюється великим числом записів і 
перевіряються типові операції  з базою даних. Щоб зробити таке тестування, в 
базу даних, у кожну з таблиць було дано по 100 000 записів і було пророблено 
типові дії для веб-сайту. Результати тестування об’ємів (час реакції застосунку на 
ці дії) представлені у таблиці 4.3. Проаналізувавши результати тестування можна 
зробити висновок, що робота з базою даних відбувається у звичайному порядку, 
хоча при наявності великої кількості записів час відгуку програми збільшується, 
але не на дуже великі величини. 
92 
ЧДТУ.232201.001 ПЗ 
Таблиця 4.3 
Результат тестування навантаженням 
Час відгуку, 
Номер тест-кейсу Опис тест-кейсу 
мс 
Авторизація користувача 
Тест кейс № 1 356 
на веб-сайті 
Реєстрація компонента 
Тест кейс № 2 467 
на веб-сайті 
Тест кейс № 3 Редагування компонента 398 
Тест кейс № 4 Видалення з БД 502 
 
4.2.4 Приймальне тестування 
Формальний процес тестування, який перевіряє відповідність системи 
вимогам і проводиться з метою: визначення чи задовольняє система 
приймальним критеріям; винесення рішення замовником або іншою 
уповноваженою особою приймається додаток чи ні. 
Приймальне тестування виконується на основі набору типових тестових 
випадків та сценаріїв, розроблених на основі вимог до даного додатку [34]. 
Рішення про проведення приймального тестування приймається тоді, коли: 
продукт досяг необхідного рівня якості; замовник ознайомлений з Планом 
приймальних Робіт (Product Acceptance Plan) або іншим документом, де описаний 
набір дій, пов'язаних з проведенням приймального тестування, дата проведення, 
відповідальні тощо. 
Фаза приймального тестування триває до тих пір, доки замовник не 
виносить рішення про відправлення програми на доопрацювання або видачі 
додатка. 
Одним із чудових наборів інструментів автоматизації є Selenium, який 
надає можливості для автоматизації дій користувача у веб-додатку. Це загальний 
93 
ЧДТУ.232201.001 ПЗ 
проект з відкритим кодом для ряду інструментів і бібліотек, які дозволяють та 
підтримують автоматизацію веб-браузерів [15] 
Для доступу до всіх цих локаторів Selenium надає клас з іменем «By», який 
допомагає знайти елементи в DOM. Він пропонує кілька різних методів: 
className, cssSelector, id, linkText, name, partialLinkText, taName і xPath, які 
можуть ідентифікувати веб-елементи на основі їх відповідних стратегій локатора 
[17]. 
ClassName використовує атрибут класу для ідентифікації об’єкта. 
cssSelector використовується для створення правил стилю для веб-сторінок 
і може використовуватися для ідентифікації будь-якого веб-елемента. 
Id може ідентифікувати елементи за допомогою атрибута 'id'. 
linkText – це текст, який використовується в гіперпосиланнях, також може 
знаходити елемент. 
partialLinkText – це частина тексту в посиланні яка також може 
ідентифікувати елемент. 
tagName використовує ім’я теуг для пошуку елементів. 
XPath (XML Path Language) — мова запитів до елементів XML або XHTML 
документа, що реалізує навігацію DOM. Призначений для використання іншими 
специфікаціями. XPath використовує вираз XML, щоб знайти елемент на 
вебсторінці. Подібно до селекторів CSS, Xpath дуже корисний для пошуку 
динамічних елементів на веб-сторінці. Може отримати доступ до будь-якого 
елемента на веб-сторінці, навіть якщо він має динамічні властивості. 
Таблиця 4.5 
Результат приймального тестування  
Функціональність Опис Тесту Результат 
Спроба підключення різних типів пристроїв до 
Підключення та 
системи. Перевірка швидкості та простоти Успішно 
ініціалізація 
ініціалізації 
Оцінка зручності користування веб-інтерфейсом та 
Взаємодія з 
мобільним додатком. Перевірка функціональності Успішно 
інтерфейсом 
та реакції на введення 
 
94 
ЧДТУ.232201.001 ПЗ 
Продовження таблиці 4.5 
Управління та Визначення можливостей керування пристроями та 
Успішно 
моніторинг ефективності моніторингу стану з пристроями 
Перевірка виконання автоматизованих завдань та 
Автоматизація та 
розкладів. Перевірка точності виконання Успішно 
розклади 
визначених користувачем сценаріїв 
Тестування заходів безпеки, включаючи 
Безпека та аутентифікацію та шифрування даних. Перевірка 
Успішно 
аутентифікація вразливостей та захисту від несанкціонованого 
доступу 
Тестування взаємодії з різними IoT-пристроями, 
Сумісність з IoT 
включаючи сумісність з популярними пристроями Успішно 
пристроями 
на ринку 
Вимірювання часу реакції системи на команди 
Загальна 
користувачів. Оцінка загальної продуктивності та Успішно 
продуктивність 
відповіді системи на завдання 
 
Основний синтаксис ідентифікації веб-елемента за допомогою стратегії 
локатора XPath: //tag_name[@attribute_value]. 
tag_name виступає у ролі імені тегу в структурі DOM, коли @attribute_value 
— це атрибут цільового елемента, який може однозначно ідентифікувати веб-
елемент. 
Тепер взаємодія з будь-яким веб-додатком вимагає, щоб драйвер Selenium 
ідентифікував веб-елементи на сторінці. Поки елемент не буде правильно 
ідентифікований, неможливо ініціювати будь-які дії над ним. 
4.3 Приклади впровадженого програмного комплексу 
У сучасних умовах системи "розумний" дім стають все більш поширеними, 
надаючи користувачам зручність та ефективність у повсякденних обов'язках. 
Використання програмного забезпечення для управління технічними засобами 
інтернету речей спрощує та автоматизує деякі аспекти їхнього функціонування. 
Використання програмного забезпечення для управління освітленням в 
системі "розумний" дім забезпечує користувачам зручність та інтелектуальний 
контроль над освітленням у їхньому житловому просторі. Програмне 
забезпечення надає можливість абстрактного та ефективного управління різними 
95 
ЧДТУ.232201.001 ПЗ 
аспектами освітлення за допомогою високотехнологічних функцій та інтерфейсу. 
Програма дозволяє користувачам точно налаштовувати яскравість світла 
відповідно до їхніх потреб та настрою. Також можливість регулювання колірної 
температури дозволяє створювати різноманітні атмосфери в приміщенні. 
Програмне забезпечення дозволяє користувачам програмувати та зберігати різні 
сценарії освітлення. Наприклад, можливість автоматично вмикати світло певного 
кольору та яскравості при певних подіях, таких як ранкове пробудження або 
вечірнє розслаблення. 
Користувачі можуть вдало управляти освітленням віддалено через веб-
інтерфейс (рисунок 4.5) . Це надає можливість вмикати та вимикати світло, 
регулювати його параметри навіть поза межами дому. Програмне забезпечення 
може інтегруватися з іншими "розумними" пристроями та системами, що 
дозволяє створювати уніфіковані сценарії для всіх підключених пристроїв. 
 
 
Рисунок 4.5 – Приклад використання програмного забезпечення для управління 
освітленістю 
 
Використання програми для управління мікрохвильовою піччю в системі 
"розумний" дім пропонує широкі можливості для зручного та інтелектуального 
керування процесом приготування їжі. Програмне забезпечення надає абстрактні 
функції та інтерфейс, що роблять використання мікрохвильової печі більш 
96 
ЧДТУ.232201.001 ПЗ 
зручним та ефективним. Користувачам надається можливість встановлювати 
точний час приготування та потужність мікрохвильової печі відповідно до вимог 
рецептів чи їхніх особистих уподобань. Користувачі можуть програмувати певні 
сценарії приготування, наприклад, автоматичне вимикання після закінчення 
таймера або приготування різних страв за певним графіком. Додаткова 
можливість дистанційного керування мікрохвильовою піччю через мобільний 
додаток або веб-інтерфейс. Це забезпечує користувачам контроль над процесом 
навіть поза межами кухні. 
Готове програмне забезпечення може інтегруватися з іншими системами 
"розумного" дому, наприклад, з системою управління освітленням чи 
температурою. Це створює можливість автоматизованого взаємодії між 
пристроями. Програма може вміти визначати оптимальний час та потужність 
приготування на основі вбудованих алгоритмів та даних про страву. В результаті 
використання програми користувачі отримують покращений рівень керованості 
та ефективності у процесі використання мікрохвильової печі (рисунок 4.6). 
 
 
Рисунок 4.6 – Приклад використання програмного забезпечення для управління 
мікрохвильовою 
 
Використання готової програми для управління витяжкою та плитою в 
системі "розумний" дім пропонує збалансований та ефективний підхід до 
97 
ЧДТУ.232201.001 ПЗ 
керування вентиляцією та готуванням їжі. Програмне забезпечення створює 
абстрактне середовище для легкого та інтуїтивного керування цими пристроями. 
Програма надає можливість автоматичного та ручного керування витяжкою. 
Користувач може встановлювати режими роботи, такі як ввімкнено, вимкнено 
або автоматичний режим залежно від потреби. Інтелектуальні алгоритми 
програми можуть автоматично регулювати швидкість вентиляції в залежності від 
рівня забруднення повітря. 
 
 
Рисунок 4.7 – Приклад використання програмного забезпечення для управління 
плитою та витяжкою 
 
Користувач може встановлювати та контролювати температуру на плиті за 
допомогою програми. Це забезпечує точний та стабільний процес готування. 
Програма дозволяє планувати роботу плити в різний час доби. Наприклад, 
можливість автоматичного ввімкнення перед приготуванням їжі або за певним 
графіком. Взаємодія з програмою може відбуватися в подальшому як за 
допомогою сенсорних екранів, так і за допомогою голосових команд, що робить 
керування більш зручним.  
Програмне забезпечення може інтегруватися з іншими системами 
"розумного" дому, спрощуючи створення комплексних сценаріїв, наприклад, 
98 
ЧДТУ.232201.001 ПЗ 
автоматичне ввімкнення витяжки при включенні плити. В результаті 
використання програмного забезпечення користувачі отримують зручний та 
ефективний інструмент для керування витяжкою та плитою, підвищуючи 
комфорт та безпеку в готельному процесі та підтримуючи здорове середовище в 
кухні. 
Впровадження програмного забезпечення для управління побутовими 
пристроями в системі "розумного" будинку суттєво покращує повсякденний 
комфорт та оптимізує витрати енергії. Забезпечуючи інтуїтивно зрозумілі 
інтерфейси та можливість дистанційного керування, це рішення дозволяє 
користувачам ефективно контролювати освітлення, кухонні прилади та інші 
пристрої. 
Такі системи спрощують щоденні обов'язки, створюючи зручні умови для 
керування різними аспектами домашнього середовища. Крім того, вони сприяють 
енергозбереженню, дозволяючи ефективно використовувати ресурси та 
автоматизувати процеси, що веде до зменшення витрат енергії та оптимізації 
вартості експлуатації.  
Такі інтелектуальні рішення також сприяють підвищенню безпеки будинку, 
дозволяючи віддалено контролювати режими пристроїв та моніторити їхні стани. 
Висновки до розділу 4 
Розробка та тестування веб-системи керування IoT-пристроями виявилися 
успішним етапом у створенні інтелектуального житлового середовища. 
Реалізований інтуїтивний та централізований інтерфейс системи дозволяє 
ефективно взаємодіяти з різноманітними IoT-пристроями, забезпечуючи зручний 
контроль та моніторинг. 
Система успішно інтегрується з різними пристроями та легко 
розширюється, що гарантує її актуальність у контексті постійно змінюючихся 
технологій. Тестування системи виявило високий рівень надійності та безпеки, 
завдяки впровадженим механізмам аутентифікації та шифрування. 
99 
ЧДТУ.232201.001 ПЗ 
Важливим аспектом є також висока працездатність системи в реальному 
часі, що дозволяє користувачам негайно взаємодіяти з пристроями та отримувати 
актуальну інформацію. Усі ці фактори роблять розроблену веб-систему 
ефективним та надійним інструментом для керування та моніторингу IoT-
пристроїв у сучасному житловому просторі. 
100 
ЧДТУ.232201.001 ПЗ 
ВИСНОВОК 
У ході дослідження "розумних" будинків був вивчений широкий спектр 
методів та моделей управління, що застосовуються у цьому секторі інновацій. 
Ретельний аналіз стану галузі дозволив визначити ключові тенденції, а також 
виявити переваги та недоліки різноманітних підходів до управління "розумними" 
будинками. Цей етап дослідження включав аналіз технічних аспектів систем, 
використання датчиків та актуаторів, а також питання енергоефективності та 
взаємодії з мережею. 
Крім того, застосовувався критичний огляд літературних джерел, який 
дозволив врахувати актуальні тенденції та передові практики в галузі "розумних" 
будинків. Це важливо для визначення напрямків розвитку та впровадження 
найновіших технологій у даній області. 
Розробка спрямовувалася на створення інтегрованого рішення, яке поєднує 
в собі архітектурний шаблон Redux і методи обробки великих обсягів даних для 
систем "розумного" будинку. Важливим етапом були експерименти, спрямовані 
на вивчення впливу Redux на швидкість та ефективність обробки даних у режимі 
реального часу. Результатом було розроблення нових стратегій оптимізації, що 
дозволяють ефективно керувати інформацією навіть в змінних умовах, таких як 
великі обсяги даних та динамічні зміни в системі. 
Створений програмний засіб для інформаційної технології управління 
"розумним" будинком вирізняється високою інтеграцією, забезпечується високий 
рівень безпеки та надає зручний інтерфейс для кінцевого користувача. Розроблені 
алгоритми та інтерфейси взаємодії є результатом врахування вивчених 
попередніх етапів та відповідають вимогам сучасного користувача. 
Отримані результати дослідження не лише вказують на наукову новизну у 
сфері управління "розумними" будинками, але також визначають нові напрямки 
для майбутнього розвитку. Інтеграція Redux та оптимізація обробки великих 
обсягів даних, а також розробка інтуїтивно зрозумілого інтерфейсу, створюють 
перспективи для розширення функціоналу та підвищення ефективності 
101 
ЧДТУ.232201.001 ПЗ 
"розумних" будинків у майбутньому. Загальна наукова новизна цього 
дослідження полягає в тому, що воно не лише ідентифікує проблеми, але й 
пропонує конкретні рішення, що створює нові можливості та перспективи для 
подальшого вдосконалення технологій "розумних" будинків. 
Майбутні напрями дослідження в області "розумних" будинків включають 
інтеграцію штучного інтелекту (ШІ) для оптимізації управління, розвиток 
безпеки та приватності, пошук нових методів поліпшення енергоефективності, та 
розробку інтуїтивних інтерфейсів для користувачів. Особлива увага має бути 
приділена захисту від кіберзагроз, розробці систем енергозбереження та 
оптимізації взаємодії між користувачем і системою. 
102 
ЧДТУ.232201.001 ПЗ 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ  
1 A Practical Evaluation of Information Processing and Abstraction Techniques for 
the Internet of Things / G. Frieder, D. Puschmann, P. Barnaghi, F. Carrez. IEEE 
Internet of Things Journal. – 2019. № 2. Р. 340–354. 
2 Al-Bahri M. Smart System Based on DOA and IoT for Products Monitoring and 
Anticounterfeiting / M. Al-Bahri, A. Yankovsky, A. Borodin, R. Kirichek // 2019 
4th MEC International Conference on Big Data and Smart City (ICBDSC). – 
IEEE, 2019. – P. 25–31. 
3 Beshley M. Investigation the modified priority queuing method based on 
virtualized network testbed / M.Beshley, V.Romanchuk, M.Seliuchenko, 
A.Masiuk // Proceedings of The XIIIth International Conference – The 
experience of designing and application of CAD Systems in microelectronics 
CADSM‘2018 (Lviv-Poljana, Ukraine, February 24-27, 2018). – Lviv: 
Publishing House of Lviv Polytechnic, 2018. – P.1-4. 
4 Beshley M. Modern problems of radio engineering, telecommunications and 
computer science Proceedings of the ХІ th International Conference 
TCSET‘2018 (Lviv – Slavske, February 21–24), 2018. – P. 281-282. 
5 Beshley M. SOA quality management subsystem on the basis of load balancing 
method using fuzzy sets / M. Beshley, M. Klymash, B.Strykhalyuk, O. Shpur, B. 
Bugil, I. Kagalo // International Journal of Computer Science and Software 
Engineering (IJCSSE). – 2018 – Volume 4 – Issue 1 – P.10-21. 
6 Branden С. J. Lambrecht. Perceptual Quality Measure using a Spatio- Temporal 
Model of the Human Visual System / C. J. Branden Lambrecht and O. 
Verscheure // Proc. SPIE. – March, 2019. – Vol. 2668. – PP. 450-461. 
7 Da B. Identity/identifier-enabled networks (IDEAS) for Internet of Things (IoT) 
//2018 IEEE 4th World Forum on Internet of Things (WF-IoT). – IEEE, 2018. – 
Р. 412–415. 
103 
ЧДТУ.232201.001 ПЗ 
8 Diao Y. The design of smart home platform based on Cloud Computing. In 
Proceeding of the International Conference on the Design of Smart Home 
Platform Based on Cloud Computing, Harbin, China, 12–14 August 2018. 
9 Gaston C. Hillar. MQTT Essentials – A Lightweight IoT Protocol / C. Hillar 
Gaston – Packt Publishing, 2020. – 280 p. 
10 Hu Q. Hardware Design of Smart Home Energy Management System with 
Dynamic Price Response. IEEE Trans. Smart Grid 2019, 4, PP. 1878–1887. 
11 Jiafu Wan. Advances in Cyber-Physical Systems Research. KSII Transactions 
On Internet And Information Systems. 2019. – Vol. 5, №11. P.1891–1908. 
12 Jules White. R&D challenges and solutions for mobile cyber-physical 
applications and supporting  Internet  service. Journal of Internet Services and 
Applications. 2020.Vol. 42, № 1. – P. 45–56. 
13 Klymash M. A Novel Approach of Optimum Multi-criteria Vertical Handoff 
Algorithm for Heterogeneous Wireless Networks‖ International Journal of 
Engineering and Innovative Technology (IJEIT)Volume 5, Issue 5, November 
2018. – РР. 41-52. 
14 Klymash M. Features of the cloud services implementation in the national 
network segment of ukraine // Information and Telecommunication Sciences, 
2019. – PP. 31-38. 
15 Koo J. Interoperability of device identification in heterogeneous IoT platforms / 
J. Koo, Y.G. Kim // 2017 13th International Computer Engineering Conference 
(ICENCO). – IEEE, 2017. – PР. 26-29. 
16 Koucheryavy A. E. The internet of Things // Elektrosvyaz. 2019. № 1. PP. 21–
24. 
17 Lakhno, V. (2020). Model of Evaluating Smart City Projects by Group of 
Investors Using a Multifactorial Approach. Applied Tecnnologies, First 
International Conference, ICAT 2019, Quito, Ecuador, December 3-5, 2019, 
Springer Nature Switzerland 2020, https://doi.org/101007/978-3-030-42517-3, 
ISSN 1865-0929, ISSN 1865-0937 (electronic) Communications in Computer 
and Information Science, PP. 13–27. 
104 
ЧДТУ.232201.001 ПЗ 
18 Lee Jay. A Cyber-Physical Systems architecture for Industry 4.0-based 
manufacturing system / Manufacturing Letter. 2019. – PР.18–23. 
19 Mardini W. Modified WRR scheduling algorithm for WiMAX networks, 
Network Protocols and Algorithms, vol. 3, n 2. – 2019. – PP. 24-53.  
20 Olivier Hersent, David Boswarthick, Omar Elloumi. The Internet of Things: Key 
Applications and Protocols. – Willey, 2019. – 370 p. 
21 Perry Lea (2018). Internet of Things for Architects: Architecting IoT solutions by 
implementing sensors, communication infrastructure, edge computing, analytics, 
and security. Packt Publishing. – РР. 526. 
22 Seliuchenko M. Development of monitoring system for end-to-end packet delay 
measurement in Software-Defined Networks / M. Seliuchenko, O. Panchenko, // 
Мodern problems of radio engineering, telecommunications, and computer 
science. Proceedings of the International Conference TCSET‘2019 (Lviv-
Slavske, Ukraine, February 23–26, 2019). – Lviv: Publishing House of Lviv 
Polytechnic, 2019. – PР. 667-670. 
23 Tsybakov B.S. Self-Similar Processes in Communications Networks [Text] / B.S. 
Tsybakov, N.D. Georganas // Information Theory, 2018. – vol.44. – no.5. – 
pp.1713- 1725. 
24 Wang, P. Joint Task Assignment, Transmission, and Computing Resource 
Allocation in Multilayer Mobile Edge Computing Systems. IEEE IoT J. 2018, 6, 
PP. 2872–2884.  
25 Антонова Г.В. Інтернет речей та бездротові смарт-мережі в точному 
землеробстві. Комп’ютерні засоби, мережі та системи. 2019. № 18. С. 119–
127. 
26 Баранов О. А. Інтернет речей (IoT): огляд правових проблем. Інтернет 
речей: проблеми правового регулювання та впровадження: матеріали 
науково-практичної конференції, 24 жовтня 2017 р., м. Київ. / упоряд.: В.М. 
Фурашев, С.Ю. Петряєв. Київ: Національний технічний університет 
України «Київський політехнічний інститут імені Ігоря Сікорського» Вид-
во «Політехніка». 2017. – 238 с. 
105 
ЧДТУ.232201.001 ПЗ 
27 Баранов О.А. Інтернет речей (IoT): мета застосування та правові проблеми. 
Інформація і право. 2018. № 2 (25). – С. 31–45. 
28 Баранов О.А. Інтернет речей і охорона здоров’я. Інтернет речей: теоретико-
методологічні основи правового регулювання : монографія. 2-ге вид. 
Харків, 2018. Т. 1: Сфери застосування, ризики і бар’єри, проблеми 
правового регулювання. С. 24–36. 
29 Баранов О.А. Інтернет речей і право: погляд у майбутнє. Інтернет речей: 
проблеми правового регулювання та впровадження: зб. матеріалів доп. 
учасн. ІІІ наук.-практ. конф. Київ, 2019. С. 7–13. 
30 Баранов О.А. Інтернет речей і сільське господарство. Інтернет речей: 
теоретико-методологічні основи правового регулювання : монографія. 2-ге 
вид. Харків, 2018. Т. 1: Сфери застосування, ризики і бар’єри, проблеми 
правового регулювання. С. 65–71. 
31 Баранов О.А. Інтернет речей і транспорт. Інтернет речей: теоретико-
методологічні основи правового регулювання: монографія. 2-ге вид. Харків, 
2018. Т. 1. С. 92–96. 
32 Баранов О.А. Інтернет речей і штучний інтелект: витоки проблеми 
правового регулювання. ІТ-право: проблеми та перспективи розвитку в 
Україні: матеріали ІІ міжнар. наук.-практ. конф., м. Львів, 17 листопада 
2017 р. Львів, 2017. С. 18–42. 
33 Бортник К.Я. Інтернет речей та як він змінить наше життя у майбутньому. 
Комп’ютерно-інтегровані технології: освіта, наука, вир-во. 2019. № 30/31. 
С. 14–18. 
34 Гордієнко Ю.Г. Інтернет речей як головний чинник впровадження ІТ-
технологій на сучасному підприємстві. Вимірювальна та обчислювальна 
техніка в технол. процесах. 2018. № 1. С. 94–98. 
35 Дідич З. «Інтернет речей»: можливості та перспективи його використання у 
сільському господарстві України. Аграрна економіка. 2018. Т. 11, № 1/2. С. 
88–93. 
106 
ЧДТУ.232201.001 ПЗ 
36 Журавель В.І. Інтернет речей у системі медичної допомоги: можливості та 
безпека. Актуальні проблеми клініч. та профілакт. медицини. 2019. Т. 3, № 
1/2. С. 5–12. 
37 Журавльов О.В. Інтернетизація та глобальна інституціоналізація 
економічних систем. Статистика України. 2019. № 4. – С. 39–46. 
38 Журавська І.М. IoT-мережа на базі Bluetooth-модулів для автоматизованого 
керування споживанням енергоресурсів. Комп’ютерно-інтегровані 
технології: освіта, наука, вир-во. 2018. № 30/31. – С. 37–44. 
39 Коваль В.В. Ринок послуг Інтернету речей (IoT): сучасний стан та 
обмеження розвитку. Трансформація економіки та права в умовах 
системних реформ України: зб. наук. пр. за матеріалами всеукр. наук.-
практ. конф. (м. Одеса, 27 жовтня 2019 року) / МОН України, Одес. торг.-
екон. ін-т [та ін.]; редкол.: Квач Я.П. [та ін.]. Одеса, 2019. С. 35–37. 
40 Костенко О.В. Ідентифікація ІоТ: Витоки проблеми правового регулювання 
управління ідентифікаційними даними. Juris Europensis Scientia. 2021. №1. – 
С. 77–83. 
41 Коцюбівська К. Впровадження технологій інтернету речей під час 
створення системи «Розумний дім». Цифрова платформа. Інформаційні 
технології в соціокультурній сфері. 2019. Т. 2, № 2. – С. 136–143. 
42 Круц А.О. Інтернет речей. Допомога чи загроза?! Матеріали другої 
науково-практичної конференції «Інтернет речей: проблеми правового 
регулювання та впровадження». – Київ, 2018. – С.60-61. 
43 Круц А.О. Особливості явища Інтернету речей в окремих сферах 
життєдіяльності. Матеріали Науково-практична конференція «Інтернет 
речей: проблеми правового регулювання та впровадження». – Київ, 2019. – 
С. 139-140. 
44 Наконечний А.Й. Інтернет речей і сучасні технології. Вісник Національного 
університету "Львівська  політехніка". Автоматика, вимірювання та 
керування. – 2020. No 852. – С. 136-138. 
107 
ЧДТУ.232201.001 ПЗ 
45 Праворська Н.І., Горященко К.Л., Підченко С.К. Розробка програмного 
забезпечення реалізації алгоритму криптографічного перетворення в 
процесорних системах для систем інтернету речей. Вісник Хмельницького 
національного університету серія: Технічні науки. С. 117 
46 Рябошлик В. Огляд сучасних технологічних проривів і нових перспектив 
(від інтернету людей до інтернету речей). Економіст. – 2019.– № 6. С. 17–
22. 
47 Рябошлик В. Огляд сучасних технологічних проривів і нових перспектив 
(від інтернету людей до інтернету речей) Економіст. 2020. № 6. – С. 17-22.  
48 Смолин О.І., Олексюк В.П. Інтернет речей як технологічний феномен XXI 
століття. Сучасні інформаційні технології та інноваційні методики 
навчання: досвід, тенденції, перспективи: матеріали ІV міжнар. наук.-практ. 
інтернет-конф. (м. Тернопіль, 30 квітня 2020 року). Тернопіль, 2020. С. 
147–149. 
49 Фещенко К.С. Інтернет речей – майбутнє інформаційного суспільства. 
Інтернет речей: проблеми правового регулювання та впровадження: 
Матеріали науково-практичної конференції. 24 жовтня 2017 р., м. Київ. / 
Упоряд.: В. М. Фурашев, С. Ю. Петряєв. Київ: Національний технічний 
університет України «Київський політехнічний інститут імені Ігоря 
Сікорського»: Вид-во «Політехніка». 2019. – С. 218-222. 
50 Яцків Н. Г. Перспективи використання технології блокчейн у мережі 
інтернет речей. Науковий вісник НЛТУ України. 2019. Вип. 26. – С. 381-
387. 
 
108
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
