1. Repository at ChSTU
  2. Випускні кваліфікаційні роботи
  3. Магістр
  4. 125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем)
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7754
Title: Система інформування про інциденти фізичного доступу на базі сервісів соціальних мереж з використанням мікроконтролерів
Authors: Кунченко-Харченко, Валентина Іванівна
Батейко, Євгеній Петрович
Keywords: фізична безпека інформаційних систем;система інформування про інциденти;мікроконтролер arduino;telegram-бот;контроль фізичного доступу;система сповіщення про інциденти
Issue Date: 2021
Abstract: Створення системи інформування про інциденти фізичного доступу на базі сервісів соціальних мереж з використанням мікроконтролерів пояснюється зручністю роботи з такими СІІФД, легкістю їх модифікації та масштабування, оперативністю отримання даних про інциденти та невисокою вартістю
URI: https://er.chdtu.edu.ua/handle/ChSTU/7754
Appears in Collections:125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем)

Files in This Item:
File Description SizeFormat 
М_125_Батейко_Кунченко-Харченко.pdf
  Restricted Access		3.31 MBAdobe PDFView/Open Request a copy
Show full item record


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
Факультет електронних технологій і робототехніки 
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
                                                            магістр                                                         . 
(освітньо-кваліфікаційний рівень) 
 
на тему: «Система інформування про інциденти фізичного доступу на базі 
                     сервісів соціальних мереж з використанням мікроконтролерів» . 
 
 
 
 
 
 
 
 
 
Виконав: студент ІІ курсу, групи БІ – 001 
Спеціальності 125 – «Кібербезпека», 
освітньої програми «Безпека інформаційних 
і комунікаційних систем» 
Батейко Є.П. 
Керівник Кунченко-Харченко В.І.                . 
                                      ( прізвище та ініціали)    
Рецензент Сагун А.В.                                     . 
(прізвище та ініціали) 
 
 
 
 
Черкаси 2021 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
(повне найменування вищого навчального закладу) 
Факультет електронних технологій і робототехніки 
(повна назва) 
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки 
(повна назва) 
Освітньо-кваліфікаційний рівень магістр 
 
Спеціальність 125 – «Кібербезпека» 
 
Освітня програма Безпека інформаційних і комунікаційних систем 
 
ЗАТВЕРДЖУЮ 
Завідувач кафедри д.т.н., проф. 
_______________ В.В. Палагін 
“___” ____________ 2021 року 
 
З А В Д А Н Н Я 
НА КВАЛІФІКАЦІЙНУ РОБОТУ МАГІСТРА СТУДЕНТУ 
 
Батейку Євгенію Петровичу 
 (прізвище, ім’я, по батькові) 
 
1. Тема роботи «Система інформування про інциденти фізичного доступу на базі сервісів 
соціальних мереж з використанням мікроконтролерів» 
керівник роботи Кунченко-Харченко Валентина Іванівна д.т.н., професор                . 
                                                                            (прізвище, ім’я, по батькові, науковий ступінь, вчене звання) 
затверджені наказом Черкаського державного технологічного університету від  
«21» _____09______ 2021року № 289-1/01 
2. Строк подання студентом роботи «20» ___12_____ 2021 р. 
3. Вихідні дані до роботи План приміщення, стандарти ISO/IEC TR 18044:2004 та ISO/IEC 
27001, сервіси соціальної мережі telegram, технічна специфікація МК Arduino                       . 
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити) 
Вступ, Розділ 1. Системи інформування про інциденти фізичного доступу в комплексній 
системі захисту підприємств та організацій, Розділ 2. Розробка структури та складу 
компонент системи інформування про інциденти фізичного доступу, Розділ 3. Реалізація, 
налаштування та тестування системи інформування про інциденти, Загальні висновки, 
Список використаних джерел, Додатки                                                                                                      . 
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів): 
мультимедійна презентація “Система інформування про інциденти фізичного доступу на 
базі сервісів соціальних мереж з використанням мікроконтролерів” – 13 слайдів (додається 
до роботи). Слайд 1 – Титульний лист; Слайд 2 –  Мета роботи; Слайд 3 – Проблеми 
забезпечення фізичної безпеки інформаційних систем; Слайд 4 – Системи сповіщення про 
інциденти безпеки та їх класифікація з точки зору нормативно-правових документів 
України; Слайд 5 – Апаратні складові системи; Слайд 6 – Послідовність створення та 
взаємодії учасників системи; Слайд 7 – Організація взаємодії компонентів системи 
інформування; Слайд 8 – Схема під’єднання ІЧ датчика присутності; Слайд 9 – Програмне 
 
 
забезпечення системи інформування про інциденти; Слайд 10 – Алгоритм створення 
telegram Bot; Слайд 11 – Тестування системи; Слайд 12 – Загальні висновки                                     . 
 
6. Консультанти розділів роботи  
Підпис, дата 
Прізвище, ініціали та посада 
Розділ завдання завдання 
консультанта 
видав прийняв 
    
    
 
7. Дата видачі завдання ________________ 
 
КАЛЕНДАРНИЙ ПЛАН  
 
Строк 
№ Назва етапів кваліфікаційної роботи 
виконання Примітка  
з/п бакалавра 
етапів роботи 
1. П ошук і аналіз інформації по заданій темі 23.09.2021-  
30.09.2021 
2. Ро зділ І. Системи інформування про  
01.10.2021-
інциденти фізичного доступу в КСЗІ 
20.10.2021 
підприємств і організацій 
3. Ро зділ ІІ. Розробка структури та складу  
21.10.2021-
компонент системи інформування про 
08.11.2021 
інциденти фізичного доступу 
4. Ро зділ ІІІ. Реалізація, налаштування та  
09.11.2021- 
налаштування системи інформування про 
24.11.2021 
інциденти 
5. Н аписання вступу і висновків, складання 25.11.2021-  
списку літератури 30.11.2021 
6. О формлення кваліфікаційної роботи магістра 01.12.2021-  
17.12.2021 
7. П одання роботи в ДЕК 20.12.2021  
8. За хист роботи в ДЕК 23.12.2021  
 
Студент ____________________Батейко Є.П.                  . 
    (підпис)                           (прізвище та ініціали) 
Керівник роботи   ____________Кунченко-Харченко В.І. 
                                                  (підпис)            (прізвище та ініціали)  
 
 
ЗМІСТ 
СПИСОК УМОВНИХ ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ ..................................... 6 
ВСТУП ..................................................................................................................... 7 
РОЗДІЛ 1 .................................................................................................................. 9 
СИСТЕМИ ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ ФІЗИЧНОГО ДОСТУПУ 
В КОМПЛЕКСНІЙ СИСТЕМІ ЗАХИСТУ ПІДПРИЄМСТВ ТА 
ОРГАНІЗАЦІЙ ........................................................................................................ 9 
1.1. Роль та місце систем інформування про інциденти фізичного доступу 
в складі КСЗІ ......................................................................................................... 9 
1.2. Проблеми забезпечення фізичної безпеки інформаційних систем ..... 11 
1.3. Інциденти безпеки та їх структура і визначення ................................... 13 
1.4. Технологія роботи систем інформування та фіксації інцидентів 
фізичної безпеки та їх вплив на систему планування КСЗІ .......................... 15 
1.4.1 Одним з методичних підходів, який часто використовується при 
розробці програми фізичної безпеки, є «запобігання здобутих злочинним 
шляхом проектування оточення» - CPTED (Crime Prevention Through 
Environmental Design). .................................................................................... 15 
1.5. Системи сповіщення про інциденти безпеки та їх класифікація з точки 
зору нормативно- правових документів України ........................................... 16 
РОЗДІЛ 2 ................................................................................................................ 18 
РОЗРОБКА СТРУКТУРИ ТА СКЛАДУ КОМПОНЕНТ СИСТЕМИ 
ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ ФІЗИЧНОГО ДОСТУПУ .................. 18 
2.1. Опис апаратної частини ........................................................................... 18 
2.1.1 Контролер для СІІФД ............................................................................ 18 
2.2. Опис датчика фіксації інцидентів фізичного доступу .......................... 22 
2.3. Вибір соціальної мережі та моделі роботи ............................................ 27 
2.4. Формулювання принципів взаємодії учасників системи ..................... 28 
  
ЧДТУ.21.20100.003 ПЗ 
Змн. Арк. № докум. Підпис Дата 
 Розроб. Батейко Є.П. Система інформування про Літ. Арк. Аркушів 
 Перевір. Кунченко-Харченко В.І. 
інциденти фізичного доступу на 4 56 
 Реценз. Сагун. А.В. базі сервісів соціальних мереж з  
 Н. Конт р. Кунченко-Харченко В.І. 
використанням мікроконтролерів ЧДТУ БІ-001 
 
 Затверд. Палагін В.В. 
2.4.1 Сервіси соціальної мережі telegram для системи інформування про 
інциденти ......................................................................................................... 29 
РОЗДІЛ 3 ................................................................................................................ 32 
РЕАЛІЗАЦІЯ, НАЛАШТУВАННЯ ТА ТЕСТУВАННЯ СИСТЕМИ 
ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ .............................................................. 32 
3.1. Налаштування апаратних компонент системи ...................................... 32 
3.2. Вибір середовища розробки та програмування мікроконтролера 
системи ................................................................................................................ 32 
3.2.1 Середовища розробки для апаратної частини системи ..................... 33 
3.2.2 Arduino IDE ............................................................................................. 33 
3.2.3 Налаштування та робота з пристроєм передачі даних WiFi 
NodeMCU CH340G та з хмарним сервером для IoT ................................... 34 
3.3. Організація взаємодії компонентів системи інформування ................. 41 
3.4. Програмне забезпечення системи інформування про інциденти ........ 43 
3.4.1 Розробка серверної частини системи ................................................... 43 
3.4.2 Програми для центрального контролера СІІФД ................................. 44 
3.5. Створення бота ......................................................................................... 46 
3.5.1 Алгоритм створення Telegram Bot ....................................................... 48 
3.6. Тестування системи .................................................................................. 51 
ЗАГАЛЬНІ ВИСНОВКИ ...................................................................................... 53 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................. 54 
ДОДАТОК А – ПРОГРАМНИЙ КОД СЕРВЕРНОЇ ЧАСТИНИ ТЕЛЕГРАМ 
БОТУ СИСТЕМИ ОПОВІЩЕННЯ ПРО ІНЦИДЕНТИ ФІЗИЧНОЇ БЕЗПЕКИ
 ................................................................................................................................. 57 
ДОДАТОК Б - ПОВНИЙ ТЕКСТ ПРОГРАМИ ГОЛОВНОГО КОНТРОЛЕРА 
СИСТЕМИ ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ ФІЗИЧНОГО ДОСТУПУ
 ................................................................................................................................. 60 
ДОДАТОК Г – ПРЕЗЕНТАЦІЯ ДО КВАЛІФІКАЦІЙНОЇ РОБОТИ .............. 62 
 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
5 
Змн. Арк. № докум. Підпис Дата  
СПИСОК УМОВНИХ ПОЗНАЧЕНЬ ТА СКОРОЧЕНЬ 
  
PDCA – plan, do, control, act; 
CPTED – crime prevention through environmental design; 
СІІФД - система інформування про інциденти фізичного доступу; 
КСЗІ – комплексна система захисту інформації; 
ISMS – система управління інформаційною безпекою; 
ІБ – інформаційна безпека; 
ІТ – інформаційні технології; 
ІКС – інформаційно-комунікаційна система; 
ІС – інформаційна система; 
АС- автоматизована система; 
ОЗУ – оперативний запам’ятовуючий пристрій; 
ПЗУ – постійний запам'ятовуючий пристрій;  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
6 
Змн. Арк. № докум. Підпис Дата  
ВСТУП 
 
Існує багато випадків, коли необхідно отримувати інформацію про ті чи 
інші інциденти, які відбуваються на об’єкті охорони. Існує багато технологій і 
методів для того, аби реалізувати таку систему [1-5]. Але дуже часто такі 
системи мають високу вартість [4], є незручними в користуванні або реалізації 
[5,6] або не можуть бути легко інтегровані в уже існуючі інформаційні системи 
[7]. Існуючі аналоги таких систем часто базуються на дорогих і непрактичних 
апаратних рішеннях або ж вимагають дорогих і складних систем забезпечення 
та обслуговування і супроводу [8,9]. 
Системи інформування про інциденти фізичного доступу (СІІФД) зараз 
стрімко розвиваються разом із розвитком сучасних інформаційних технологій. 
Одним з перспективних напрямів розвитку СІІФД – це їх інтеграція з 
сервісами соціальних мереж. Мікроконтролери в СІІФД є апаратною основою, 
які використовуються для отримання у фізичному виді інформації про 
інциденти доступу. 
Актуальність створення системи інформування про інциденти 
фізичного доступу на базі сервісів соціальних мереж з використанням 
мікроконтролерів пояснюється зручністю роботи з такими СІІФД, легкістю їх 
модифікації та масштабування, оперативністю отримання даних про 
інциденти та невисокою вартістю. Зараз велика кількість підприємств різної 
форми власності, приватні особи потребують подібних рішень.  
Новизною роботи є підхід, щодо створення інформаційної системи 
інформування про інциденти фізичного доступу в рамках стандартів ISO/IEC 
TR 18044:2004 та ISO/IEC 27001 та з використанням сервісів соціальної мережі 
telegram та Arduino сумісних мікроконтролерів з наднизьким 
енергоспоживанням. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
7 
Змн. Арк. № докум. Підпис Дата  
Для розв’язку даної задачі слід розв’язати наступні підзадачі: 
1. Проаналізувати роль і місце систем інформування про інциденти 
фізичного доступу в складі КСЗІ та нормативні документи, щодо їх функцій 
та складу; 
2. розробити структуру системи інформування та алгоритм її роботи, 
обрати схемотехнічне рішення апаратні компоненти та логіку їх взаємодії, 
обрати базову соціальну мережу для організації підсистеми інформування та 
потрібні сервіси; 
3. створити програмний код окремих програмних модулів та 
запрограмувати апаратні компоненти системи інформування про інциденти; 
4. налаштувати та протестувати систему на функціональність, 
провести оцінку адекватності створеної системи стандартам відповідності 
стандарту управління інформаційною безпекою ISO/IEC 27001. 
Об’єктом дослідження в даній роботі є система інформування про 
інциденти фізичного доступу. 
Предметом дослідження є механізми та системи обробки статистики 
про інциденти фізичного доступу. 
В роботі використані методи композиції та декомпозиції інформаційної 
системи, методи симуляційного та імітаційного моделювання інформаційно-
телекомунікаційних систем, методи та прийоми об’єктно-орієнованого 
програмування. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
8 
Змн. Арк. № докум. Підпис Дата  
РОЗДІЛ 1 
 
СИСТЕМИ ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ ФІЗИЧНОГО 
ДОСТУПУ В КОМПЛЕКСНІЙ СИСТЕМІ ЗАХИСТУ ПІДПРИЄМСТВ 
ТА ОРГАНІЗАЦІЙ 
 
1.1. Роль та місце систем інформування про інциденти фізичного 
доступу в складі КСЗІ 
 
Хоча сьогодні Законом, підписаним президентом України від 1 липня 
2021 фактично відміняється виконання вимог по КСЗІ для державних 
організацій, все ж таки існують Нормативні акти України, яких слід 
додержуватися при створенні, впровадженні і підтримці таких систем. Зараз, 
замість відміненого «застарілого» національного стандарту захисту 
інформації застосовуються чинні в Європейському союзі стандарти Системи 
управління інформаційною безпекою (ISMS) [10].    
У свою чергу, тепер замість КСЗІ запропоновано використовувати 
стандарт ISO/IEC 27001 – один із найвідоміших стандартів у сфері систем 
управління інформаційною безпекою. Даний стандарт являє собою набір 
політик та процедур, згідно з якими компанія може захищати свої 
інформаційні активи від навмисного чи випадкового неправильного 
використання, втрати чи пошкодження. 
У підході ISO до стандартизації закладено принцип, за яким жодна 
система неспроможна постійно перебувати у ідеальному стані. Тому там, де у 
КСЗІ вказані чіткі робочі схеми, ISO містить лише рекомендації. 
Таким чином для сертифікації КСЗІ (отримання сертифікату 
відповідності ISO/IEC 27001) не обов'язково на момент сертифікації 
дотримуватись усіх вимог зазначеного стандарту – достатньо взяти на себе 
зобов'язання протягом року доробити все необхідне. 
Тобто, визначення КСЗІ, як сукупності організаційних та інженерно-
технічних заходів, спрямованих на забезпечення захисту інформації від 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
9 
Змн. Арк. № докум. Підпис Дата  
розголошення, витоку та несанкціонованого доступу наразі залишається 
актуальним. Отже, якщо дотримуватися даного підходу, то інциденти 
фізичного доступу є частиною прописаних у документах серії ISO/IEC 27001 
можливо залишити віднесеними до інженерно-технічних заходів захисту 
інформації. 
Таким чином, відповідно до того ж міжнародного стандарту ISO/IEC TR 
18044:2004 СІІФД є частиною загальної схеми КСЗІ. Тому роль створюваних 
систем інформування про інцидент фізичної безпеки розглядається в пункті 
менеджменту інцидентів ІБ. 
Менеджмент інцидентів ІБ відноситься до управління екаунтінгом, яке 
пов'язане з процесом збору, обробки та аналізу даних про роботу організації, 
їх порівняння з вихідними і плановими показниками, з метою своєчасного 
виявлення проблем, розкриття резервів для більш повного використання 
наявного потенціалу. 
Відповідно до існуючого нормативно правового документу ДСТУ ISO / 
IEC 27001-2006 «Інформаційна технологія. Методи і засоби забезпечення 
безпеки. Системи менеджменту інформаційної безпеки. Вимоги» ця система, 
до складу якої і включаються системи інформування про різні види інцидентів 
визначається в якості частини загальної системи менеджменту, яка заснована 
на використанні різноманітних методів оцінки бізнес-ризиків, які виникають 
при функціонуванні створеної КСЗІ в процесі розробки, впровадження, 
функціонування, моніторингу, аналізу, підтримки та подальшого поліпшення 
стану інформаційної (кібер) безпеки [10]. 
Як було сказано вище, складовою частиною системи загального 
менеджменту ІБ є система менеджменту інцидентів ІБ, призначена для 
комплексного вирішення наступних завдань: 
− Виявлення, інформування та облік інцидентів ІБ; 
− реагування на інциденти ІБ, включно із застосуванням 
необхідних засобів для запобігання, зменшення і відновлення завданих 
збитків; 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
10 
Змн. Арк. № докум. Підпис Дата  
− аналіз інцидентів з метою планування превентивних заходів 
захисту і поліпшення процесу забезпечення ІБ в цілому. 
 
1.2.  Проблеми забезпечення фізичної безпеки інформаційних 
систем  
 
Забезпечення безпеки ресурсів інформаційних комп'ютерних систем 
істотно ускладнюється у випадках фізичних зіткнень зловмисника з системою. 
Крім того, рівень інформаційної безпеки організації або фізичної особи може 
бути знижений також через ненавмисні фізичні ушкодження наявної 
інфраструктури та ресурсів системи. З огляду на це питання фізичної безпеки 
зачіпаються в рамках розділу забезпечення підтримки КСЗІ «Сертифікований 
професіонал в області безпеки інформаційних систем» в якості обов'язкового 
атрибуту довіри до комп'ютерних систем. 
Частіше за все, на практиці в політиках безпеки ІТ-організації питання 
фізичної безпеки відображаються неповно або взагалі виносяться за рамки 
технічного захисту інформації. 
Традиційно загрози фізичній безпеці поділяють на природні (природні), 
штучні (техногенні), а останні - на випадкові і навмисні. Однак на 
класифікацію загроз фізичній безпеці вплинули різні служби, що історично 
склалися ще до формування поняття кібербезпеки. Наприклад, в рамках 
фізичної безпеки виділяють загрози:  
− Загрози систем забезпечення ІТ-організації (електрики і зв'язку); 
− загрози пожежної безпеки; 
− загрози, пов'язані з персоналом тощо. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
11 
Змн. Арк. № докум. Підпис Дата  
Класи та види загроз інформаційній безпеці ІКС підприємств, 
організацій та фізичних осіб, які мають фізичне походження наведено на 
Рис.1.1. 
 
Природні Штучні 
Загрози систем Загрози Загрози через дії 
забезпечення пожежної персоналу 
безпеки 
 
 
Рис.1.1 - Класи та види загроз, які мають фізичне походження 
 
Сьогодні не існує конкретної статистики, яка б відображала кількість 
інцидентів фізичного доступу до інформації на підприємствах, організаціях 
або стосувалася б фізичних осіб. Наприклад, за даними сайту anti-malware.ru 
(Рис.1.2), у 2019 році серед зареєстрованих інцидентів інформаційної безпеки, 
які фіксуються в роботі ІКС та стосуються порушення фізичної безпеки, 
можна віднести декілька типів [11]. 
Наприклад, з порушенням фізичної безпеки можна частково пов’язати: 
− Несанкціонований доступ до інформації; 
− виток конфіденційних даних; 
− злам веб-ресурсів. 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
12 
Змн. Арк. № докум. Підпис Дата  
 
 
Рис. 1.2. – Зареєстровані інциденти інформаційної безпеки по типам 
 
За територіальною ознакою загрози ділять на внутрішні і зовнішні. 
Фізичну безпеку, також як багато інших питань інформаційної безпеки, зручно 
розглядати в рамках моделі PDCA (plan, do, control, act), ефективність якої 
задається першим етапом - плануванням [12]. 
 
1.3. Інциденти безпеки та їх структура і визначення 
 
Інциденти безпеки з точки зору ДСТУ ISO/IEC 18044-2007 віднесені до 
подій інформаційної безпеки. За своєю суттю інцидент безпеки – це 
ідентифікована поява певного стану системи, сервісу або мережі, що вказує на 
можливе порушення політики ІБ або відмова захисних заходів, або 
виникнення невідомої раніше ситуації, яка може мати відношення до безпеки 
[10]. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
13 
Змн. Арк. № докум. Підпис Дата  
Відповідно до іншого нормативного акту - ДСТУ ISO/IEC 27001:2006, 
інцидент інформаційної безпеки: будь-яка непередбачувана або небажана 
подія, яка може порушити діяльність або інформаційну безпеку [2].  В 
стандарті наводиться також перелік основних видів інцидентів інформаційної 
безпеки: 
− Втрата послуг, обладнання або пристроїв; 
− системні збої або перевантаження; 
− помилки користувачів; 
− недотримання політики або рекомендацій по інформаційній 
безпеці; 
− порушення фізичних заходів захисту; 
− неконтрольовані зміни систем; 
− збої програмного забезпечення та відмови технічних засобів;  
− порушення правил доступу. 
Сповіщення - це повідомлення, які датчик або інший сенсор СІІФД 
генерує при виявленні загроз для ресурсів. Саме налаштування контролера 
визначають пріоритети і відображають оповіщення, а також відомості, 
необхідні для швидкого вивчення місця та характеру спроби зловмисника. У 
програмі роботи СІІФД також містяться докладні інструкції щодо можливих 
механізмах захисту від атак. Дані сповіщень, як правило зберігаються якийсь 
час в системі. 
Інцидент системи інформування про інциденти являє собою набір 
пов'язаних сповіщень, а не просто список окремих повідомлень. Контролер 
системи використовує інтелектуальну кореляцію хмарних сповіщень для 
зіставлення різних оповіщень і сигналів з низькою вірогідністю з інцидентами 
системи безпеки. 
За рахунок наявності СІІФД в функціонуючій КСЗІ забезпечується 
цілісна картина про серії кібератак, їх характер та мету. Це уявлення дозволяє 
швидко зрозуміти, які дії виконав зловмисник і які ресурси були порушені. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
14 
Змн. Арк. № докум. Підпис Дата  
1.4. Технологія роботи систем інформування та фіксації інцидентів 
фізичної безпеки та їх вплив на систему планування КСЗІ 
 
Для того, аби створена система інформування про інциденти могла бути 
сформована та реалізована необхідно отримати рішення про необхідність її 
створення. Для цього потрібно позитивне рішення з боку керівництва. Таке 
рішення базується на необхідності забезпечення фізичної безпеки організації, 
після чого формується група розробників програми фізичної безпеки, яка 
(спільно з керівництвом) повинна визначити основні цілі програми, а також 
показники, за якими дана програма буде оцінюватися після створення на 
предмет того, що всі поставлені цілі досягаються. 
У сформованої цією групою програмі повинні враховуватися наступні 
цілі: 
− Запобігання злочинам та руйнувань за допомогою стримування 
(залякування); 
− зменшення пошкоджень за допомогою використання 
затримуючих механізмів; 
− виявлення вторгнень або пошкоджень; 
− оцінка інцидентів; 
− процедури реагування. 
 
1.4.1 Одним з методичних підходів, який часто використовується при 
розробці програми фізичної безпеки, є «запобігання здобутих злочинним 
шляхом проектування оточення» - CPTED (Crime Prevention Through 
Environmental Design). Цей підхід має на меті сформувати відповідь на питання 
про те, як правильно спроектувати фізичне оточення, щоб знизити 
ймовірність, можливість злочинів, що пов’язані з інцидентами фізичної 
безпеки, і пропонує три стратегії [13]: 
− Природне управління доступом; 
− природне спостереження; 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
15 
Змн. Арк. № докум. Підпис Дата  
− природне укріплення території. 
Природне управління доступом (natural access control) - це стратегія, 
спрямована на управління доступом персоналу та відвідувачів території, 
периметру або приміщення, об’єкти що охороняються на даній території. 
Природне спостереження - це стратегія, спрямована на забезпечення 
максимальної видимості території навколо будівлі або території охорони, або 
всередині неї. 
Мета даної стратегії - створення некомфортних умов для зловмисника. 
Природне зміцнення території (natural territorial reinforcement) - це 
стратегія, спрямована на створення фізичного захисного оточення. 
 
1.5. Системи сповіщення про інциденти безпеки та їх класифікація 
з точки зору нормативно- правових документів України 
 
В залежності від топології ІС, складу системи інформування та інших 
факторів, такі системи можуть бути віднесені до 3 класів [14]: 
− Клас «1» – одномашинний однокористувачевий комплекс, що 
обробляє інформацію однієї або кількох категорій конфіденційності; 
− Клас «2» – локалізований багатомашинний 
багатокористувачевий комплекс, що обробляє інформацію різних категорій 
конфіденційності; 
− Клас «3» – розподілений багатомашинний 
багатокористувачевий комплекс, що обробляє інформацію різних категорій 
конфіденційності. 
В той же час можна виділити підкласи, які будуть характерні для систем 
інформування про інциденти фізичної безпеки з огляду на коло виконуваних 
ними задач.  
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
16 
Змн. Арк. № докум. Підпис Дата  
В зв’язку з цим, в кожному класі АС виділяються декілька підкласів 
таких систем [13]. Але для СІІФД найбільш слушними будуть такі підкласи: 
− Автоматизована система, в якій підвищені вимоги до — 
забезпечення цілісності оброблюваної інформації (підкласи «х.Ц»);  
− автоматизована система, в якій підвищені вимоги до — 
забезпечення цілісності і доступності оброблюваної інформації (підкласи 
«х.ЦД»). 
Це пов’язано з тим, що захисту в таких ССІФД підлягають перш за все: 
Цілісність – через те, що дані про інциденті фізичного доступу повинні 
достовірно бути фіксовані і сприйняті суб’єктом нагляду (оператором). 
Доступність – тому, що сигнали з датчиків ССІФД мають бути швидко і 
гарантовано доставлені до головного контролера ССФІД і бути зафіксованими 
та переданими оператору. 
Захист всіх інших властивостей не має серйозного значення в реальних 
умовах функціонування таких систем. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
17 
Змн. Арк. № докум. Підпис Дата  
РОЗДІЛ 2 
 
РОЗРОБКА СТРУКТУРИ ТА СКЛАДУ КОМПОНЕНТ СИСТЕМИ 
ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ ФІЗИЧНОГО ДОСТУПУ 
 
2.1. Опис апаратної частини 
 
2.1.1 Контролер для СІІФД 
В якості базового елемента СІІФД планується використовувати 
мікроконтролер. Мікроконтролер - це мікросхема, призначена для управління 
електронними пристроями. Існує декілька різних архітектур та видів 
мікроконтролерів. 
Типовий мікроконтролер поєднує в одному кристалі функції процесора, 
периферійних пристроїв, містить ОЗУ і (або) ПЗУ.  Такий пристрій являє 
собою часто однокристальний комп'ютер, здатний виконувати відносно прості 
завдання. Але до контролера СІІФД пред’являється ряд специфічних вимог, 
зокрема: 
− Компактні розміри; 
− висока автономність роботи; 
− функціональність; 
− достатня продуктивність; 
− наявність wi-fi інтерфейсу; 
Функції контролерів зазвичай такі: 
− Прийом даних від пристроїв нижніх рівнів; 
− вимірювання і попередня обробка - при роботі з 
неінтелектуальними датчиками; 
− керування мережами типу FieldBus - при роботі з 
інтелектуальними датчиками; 
− вторинна обробка даних і реалізація алгоритмів керування;  
− апаратна підтримка мереж і протоколів FieldBus; 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
18 
Змн. Арк. № докум. Підпис Дата  
− апаратна підтримка мереж верхнього рівня; 
− дистанційне керування та завантаження програм; 
− відмовостійкість та самодіагностика. 
Найбільш придатними відповідно до окреслених вимог є 
мікроконтролери, що базуються на платформі AVR. Найпоширеніші 
представники даної платформи – МК Arduino. За своїм початковим 
призначенням – це електронний конструктор і зручна платформа швидкої 
розробки електронних пристроїв для новачків і професіоналів. Дана 
платформа користується великою популярністю в усьому світі завдяки 
зручності і простоті мови програмування, а також відкритої архітектури і 
програмного коду.  
Пристрій на базі СКС Arduino програмується через USB – порт без 
використання програматорів, що є великою перевагою. До того ж, в разі 
необхідності виправлення завантаженої програми це можна зробити через 
звичайний USB-кабель. 
Одним з популярних контролерів, які мають інтерфейс Wi-Fi є чіп ESP 
8266. Він використовується з різними дизайнами елементів на платі. В якості 
апаратного інтерфейсу зв’язку та прошивки використовується чіп CH340G. 
Контролер NodeMCU (Lolin) являє собою плату розробника на базі чіпа 
ESP8266 (версія ESP12E), який являє собою UART-WiFi модуль з ультра 
низьким споживанням [15]. Сам чіп проєктувався для пристроїв зі світу 
інтернет речей, а дана плата дозволяє спростити розробку, тому що на ній вже 
реалізовано підключення по USB, регулятор живлення і всі виводи чіпа 
розведені на гребінки зі стандартним кроком 2.54 мм, що дозволяє вставити 
його в макетну плату і створити натурний макет СІІФД. Крім цього плата 
поставляється з прошивкою NodeMCU, що дозволяє програмувати її за 
допомогою мови Lua або за допомогою Arduino IDE [15]. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
19 
Змн. Арк. № докум. Підпис Дата  
З підключеним живленням МК NodeMCU 1.1 виглядає так (Рис. 2.1). 
 
 
 
Рис. 2.1. – Зовнішній вигляд МК ESP 8266 з модулем Wi-Fi 
 
Основні технічні характеристики Arduino-сумісного спеціалізованого 
комп’ютера Node MCU з модулем WiFi наступні: 
− Мережевий інтерфейс WiFi 802.11 b / g / n; 
− підтримка STA / AP / STA + AP режимів; 
− вбудований стек протоколів TCP/IP з підтримкою множинних 
клієнтських підключень (до 5); 
− виводи D0 - D8, SD1 - SD3: можуть бути використані як GPIO, 
PWM, IIC, тощо; 
− струм на виведення: 15 мА; 
− AD0: 1 виведення АЦП; 
− живлення: 4.5 - 9В (10В максимум), живлення від USB з 
наданням відлагоджувального інтерфейсу; 
− споживання: обмін даними: ~ 70 мА (200 мА максимум), 
очікування: <200 мкА; 
− швидкість передачі даних: 110-460800 біт/сек; 
− підтримка UART / GPIO інтерфейсів передачі даних; 
− перепрошивка з хмари або через USB; 
− відстань між контактними пінами: 28 мм; 
− діапазон робочих температур: -40…+125 ° C; 
− об’єм флеш - пам’яті – до 4Мб; 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
20 
Змн. Арк. № докум. Підпис Дата  
− тактова частота мікропроцесорного ядра МК – 80 МГц 
(максимально, до 160 МГц). 
МК NodeMCU є платою, на якій розміщені сам модуль ESP-8266, 
стабілізатор напруги і USB-UART мост. 
Плата NodeMCU2 яка початково розроблялася для роботи в складі 
технології «Інтернет речей» здатна зв'язати фізичний об'єкт (реле, датчики і 
так далі) з мережею Інтернет. 
 
2.1.2 Датчик для системи СІІФД 
Для даної платформи існує велика кількість датчиків та виконавчих 
пристроїв, які дозволяють створити на даній платформі велику кількість 
різних пристроїв. Так, на Рис. 2.2 показані різноманітні види датчиків, сумісні 
з платформою Arduino, які застосовуються в якості охоронних. 
 
   
 
  
 
Рис. 2.2. – Види охоронних датчиків для Arduino 
 
Для застосування в якості датчика фіксації інцидентів фізичного доступу 
використовуємо, наведений на Рис. 2.2 ІЧ-датчик присутності hc-sr501. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
21 
Змн. Арк. № докум. Підпис Дата  
2.2. Опис датчика фіксації інцидентів фізичного доступу 
 
У якості модуля спеціалізованої комп’ютерної системи, яка реалізує 
функції охоронної сигналізації (особливо в складі систем типу «Розумний 
дім»). Для подібних систем взагалі часто обирають датчики, які дозволяють 
відслідковувати рух – піроелектричні інфрачервоні (PIR) датчики руху моделі 
hc-sr501 (Рис. 2.3).  
 
 
Рис. 2.3. – Датчики руху (присутності) моделі hc-sr501 
 
Вибір датчика саме інфрачервоного типу пов'язаний з тим, що вони 
мають мініатюрні розміри, можуть встановлюватися окремо або підключатися 
до апаратної частини системи безпосередньо. Їх можна встановити практично 
в кожному приміщенні. Такі датчики прості у використанні та налаштуванні, 
можуть бути легко інтегровані в будь-який проект СКС на Arduino або 
Raspberry Pi тощо. 
Приклади ситуацій і місць, де розташувати такий датчик руху: 
− Автоматичне ввімкнення світла в під'їзді будинку, у ванній 
кімнаті або туалеті, перед вхідними дверима в приміщення; 
− сигналізація в приміщенні і на подвір'ї; 
− автоматичне відкривання дверей; 
− автоматичне включення охоронної відеокамери. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
22 
Змн. Арк. № докум. Підпис Дата  
Цей модуль невеликий за розмірами, споживає малий струм і є дуже 
простий у використанні, завдяки чому його можна використовувати і в 
пристроях сигналізації з автономним живленням. 
Характеристики датчика наступні []: 
1. Діапазон робочої напруги: 4,5 – 20 В постійного струму; 
2. споживаний струм, в стані спокою: ≈50 мкА; 
3. напруга на виході: 3.3 В; 
4. робоча температура: від -15° C до 70° C; 
5. розміри: 32*24 мм; 
6. два режими роботи; 
7. максимальний кут виявлення – 110°; 
8. максимальна дистанція спрацьовування – від 3 до 7 м 
(регулюється). При температурі вище 30° C відстань реагування може 
зменшуватися; 
9. на модуль встановлена лінза Френеля, яка фокусує інфрачервоні 
сигнали на піроелектричному сенсорі під назвою 500BP. Датчик називається 
PIR (Passive Infra-Red). Пасивний він називається тому, що для виявлення руху 
не використовується будь-яка додаткова енергія, крім тієї, що випромінюється 
самими об'єктами. 
Модуль детектора даного датчика моделі 500BP складається з двох 
чутливих елементів (Рис. 2.4). Керуюча схема модуля реєструє зміни рівню 
сигналу від обох елементів. Вона здатна за характером їх зміни виявляти рух 
об'єктів, які випромінюють інфрачервоне випромінювання. В якості таких 
об’єктів система інформування про інциденти фізичного доступу фіксуватиме 
можливого зловмисника. 
Модуль HC-SR501 датчика присутності зловмисника має 3 апаратних 
виводи: 
− Живлення (Vсс); 
− земля (GND); 
− вихід 3v3 (OUT). 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
23 
Змн. Арк. № докум. Підпис Дата  
 
 
 
Рис. 2.4. – Зовнішній вигляд датчику руху моделі hc-sr501 з ІЧ - сенсорами 
типу 500BP 
 
Через 1-2 секунди після подачі живлення модуль ІЧ –сенсору калібрує 
сигнал. В цей час цілком можливі помилкові спрацьовування СІІФД. 
Приблизно за хвилину датчик переходить в режим очікування. При 
спрацьовуванні датчика на виході з'явиться сигнал логічної одиниці. Опорна 
напруга для роботи датчика - 3.3 В постійного струму. 
Логіку реагування на рівень сигналу даного датчика можна змінити. Він 
змінюється спеціальним перемикачем на платі (jumper). При виборі режиму 
«H-» при декількох спрацьовуваннях поспіль на виході датчика залишиться 
високий рівень сигналу, а в режимі «L-» для кожного спрацьовування буде 
поданий окремий імпульс. 
Також на платі модулі даного ІЧ датчика встановлені два змінних опори, 
через налаштування яких можна регулювати дистанцію виявлення руху 
(Distance Adjust) і час формування на виході сигналу логічної одиниці (Delay 
Time Adjust).  
Дистанцію реагування ІЧ сенсора даного датчика можна регулювати в 
межах 3 - 7 метрів. Такої відстані цілком достатньо з огляду на розміри 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
24 
Змн. Арк. № докум. Підпис Дата  
приміщення, де буде відбуватися фіксація інцидентів фізичного доступу (Рис. 
2.5). 
 
 
 
Рис. 2.5. – Схема приміщення для встановлення датчика СІІФД 
 
Затримка на спрацювання даного датчика при реагуванні складає від 5 
до 300 секунд. 
При встановленні даного датчика з метою уникнення помилкових 
спрацьовувань він не встановлюється поблизу джерел світла і тепла. В процесі 
експлуатації СІІФД слід уникати перекривання сенсора датчика в районі 
поверхні об'єктива модуля. В противному випадку можливі сбої в роботі 
СІІФД. Сильний вітер і протяги також можуть створювати перешкоди для 
роботи сенсору фіксації датчика присутності. Чим більше відстань реагування 
до датчика, тим більш чутливим він виявляється. 
На Рис. 2.4 видно розташування апаратних виводів датчика HC-SR501: 
− GND підключається до відповідного виходу МК Arduino; 
− VCC до 5V; 
− OUT підключається до порту A0 МК Arduino. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
25 
Змн. Арк. № докум. Підпис Дата  
Підключення модуля датчика до аналогового порту МК пов'язано з тим, 
що цифрові порти МК Arduino працюють з сигналами рівнем 5В, а даний 
модуль розрахований на 3.3 В. У програмі (скетчі) за логічну одиницю 
приймемо значення більше 500 одиниць на аналоговому порту, тобто, 
приблизно 2.44 В і більше [15]. 
Схема підключення датчика присутності hc-sr501 до МК NodeMCU 
показана на Рис. 2.6. 
 
 
 
Рис. 2.6. – Схема підключення датчика присутності до контролера NodeMCU 
 
До даного мікроконтролера можна підключити декілька аналогічних 
датчиків, чим можна значно розширити зону фіксації інцидентів безпеки. За 
принципом роботи з контролером всі подібні датчики є дискретними, а даний 
МК має від 10 дискретних портів для підключення подібних пристроїв. Це дає 
змогу в майбутньому (за необхідності) значно розширити зону нагляду і 
фіксації інцидентів безпеки. Але сумарна потужність, яку споживають 
датчики при роботі не має перевищувати загальної навантажувальної 
здатності системи живлення мікроконтролера NodeMCU. 
Цифровий вихід датчика HC-SR501 генерує високий рівень сигналу при 
спрацьовуванні. Можна написати просту програму(скетч), яка буде 
відправляти в цифровий порт «1» у випадку фіксації руху, і логічний «0» в 
іншому випадку [15]. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
26 
Змн. Арк. № докум. Підпис Дата  
2.3.  Вибір соціальної мережі та моделі роботи 
 
Існує багато засобів для інформування адміністраторів або інших 
зацікавлених осіб про зафіксовані випадки порушення периметру охорони. 
Якщо в якості агенту зв’язку та обробника подій використовується соціальні 
мережі, то існує зручний інструментарій, який дозволяє це реалізовувати в 
наступних мережах: 
− VK; 
− Telegram; 
− Twitter. 
Для використанні в даній роботі обрано мережу Telegram. Такий вибір 
обумовлений 5 причинами: 
1. Легкість реалізації взаємодії учасників; 
2. відсутність необхідності створювати власне API (бот і є тим самим 
API) або вивчати стороннє для встановлення зв’язку із сервером; 
3. висока оперативність роботи створюваної на базі мережі Telegram 
СІІФД; 
4. велика популярність мережі Telegram та її кросплатформеність 
(додаток telegram може бути встановлений практично на будь-яку популярну 
операційну систему); 
5. високий рівень підтримки, захищеність та стабільність роботи 
мережі Telegram. 
Завдяки даним факторам соціальна мережа telegram і була обрана в 
якості базового сервісу взаємодії та інформування про інциденти фізичного 
доступу.  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
27 
Змн. Арк. № докум. Підпис Дата  
2.4. Формулювання принципів взаємодії учасників системи 
 
Для реалізації технології взаємодії учасників СІІФД необхідно 
дотриматися наступної послідовності дій: 
1. Створення бота; 
2. створення домена на хостінг-платформі для розміщення 
функціонального web-сервера СІІФД. Передавання інформаційного трафіку 
повинно відбуватися через захищений протокол https, отже потрібна його 
підтримка на хості; 
3. створення файлу на серверній частині для приймання повідомлень 
від WEBHOOK формату; 
4. реєстрація для бота адреси у WEBHOOK; 
5. створення на серверній стороні програмного модуля для 
приймання і відправки повідомлень для/на telegram бота. 
Графічна схема взаємодії учасників системи оповіщення про інциденти 
фізичної безпеки на базі соціальної мережі показана на Рис.2.7. 
 
 
Рис. 2.7. – Графічна схема взаємодії учасників системи оповіщення про 
інциденти фізичної безпеки на базі соціальної мережі  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
28 
Змн. Арк. № докум. Підпис Дата  
В технології взаємодії програмних компонент СІІФД використовується 
механізм Webhook — механізм оповіщення системи про події. 
В даній технології взаємодії учасників системи розробці підлягають: 
1. Web-сервер – програмний код, який реалізує функціонал по 
прийманню та обробці повідомлень про інциденти безпеки від центрального 
контролера і їх відправка через telegram API – бот; 
2. telegram – bot. Боти в соціальній мережі Telegrаm — спеціальні 
акаунти в Telegram, які створені для того, щоб автоматично обробляти та 
надсилати повідомлення. Користувачі можуть взаємодіяти з ботами за 
допомогою повідомлень, що надсилаються через звичайні або групові чати. 
Логіка роботи ботів в Telegram контролюється за допомогою HTTPS запитів 
до API для роботів. Такі роботи — особливі облікові записи, які не потребують 
номера телефону під час створення. По суті, це облікові записи, що відіграють 
роль інтерфейсу до сервісу користувача, який працює на віддаленому сервері; 
3. припустимо, є певний сервіс, який повинен сповіщати про події, 
коли вони відбуваються. Даний сервіс постійно запитує нові дані на сервері, 
він буде швидше отримувати дані, якщо на сервері, наприклад, стоїть затримка 
на отримання нових оповіщень. Webhook виправляє цей недолік, коли 
відбувається подія, він запитує адресу сайту з параметрами, наприклад 
example.com/webhook/notification і передає в тілі POST запиту JSON (часто) і 
там будуть свіжі дані. 
 
2.4.1 Сервіси соціальної мережі telegram для системи інформування про 
інциденти 
Популярний додаток «Телеграм» надає своїм зареєстрованим 
користувачам безліч функціональних інструментів для спілкування, розваг, а 
також ведення бізнесу. Його основними опціями є обмін повідомленнями і 
файлами, створення чатів, можливість ведення секретного листування. Крім 
основного функціоналу, в «телеграмі» існує величезна кількість ботів, 
корисних і розважальних. Бот – це, як правило програма, створена на одній з 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
29 
Змн. Арк. № докум. Підпис Дата  
популярних (або не дуже) мов програмування. Їх може створювати під свої 
потреби кожен бажаючий користувач даного популярного месенджера (Рис. 
2.8). 
 
 
 
Рис. 2.8 - Логотип месенджера Telegram 
 
«Телеграм» використовує протоколи для соціальних мереж, де особисті 
акаунти і спільноти (чати, канали) розпізнаються за допомогою спеціального 
чисельного ідентифікатора. Унікальний номер даного ідентифікатора (ID) 
необхідний системі (telegram) для точної ідентифікації користувача. Навіть 
програми всередині месенджера використовують набір певних чисел для 
зручності використання сервісу. Завдяки унікальному номеру, який 
присвоюється при створенні сторінки користувачу або боту, система бачить і 
розуміє, які дані користувача або яке листування слід відображати, а яке не 
слід. Обмін даними починається відразу ж після проведення авторизації та 
ідентифікації профілю, тобто при вході в аккаунт шляхом введення логіна і 
пароля. 
При створенні групи (неважливо, приватної або публічної), також 
генерується ID, в даному випадку він потрібен для доступу до неї. Інформація 
про ідентифікатор знадобитися при реалізації оповіщення користувача про 
події (для налаштування і коректної роботи бота, що зв'язується з 
користувачами і чатами). Щоб відправити повідомлення через «Telegram» API, 
боту потрібно знати ID чату, в який він буде писати. 
Отже, для того, аби використовувати сервіси даного месенджера для 
конструювання IoT дуже важливо знати ID користувача. 
Основний функціонал месенджера не дозволяє дізнаватися 
ідентифікатор чату або свій, розробниками не передбачена ця опція. У ранніх 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
30 
Змн. Арк. № докум. Підпис Дата  
версіях «Телеграма» можна було побачити ідентифікатор з посиланням 
запрошення спільноти, подивитися ID створювача групи, а також користувача, 
який зробив будь-який запис в чаті. Наразі зараз розробники telegram прибрали 
цю помилку, адже месенджер позиціонує себе як найбільш безпечний, а 
висвітлення такої конфіденційної інформації, яку може дізнатися кожен, в 
кого є таке бажання, в telegram вирішили прибрати. 
Проте, іноді може знадобитися отримати номер власного ID або 
ідентифікатора бесіди з ботом. Для отримання цієї інформації користувачами 
були створені спеціальні боти. Крім того, якщо знати токен, то отримати chat 
id можна за допомогою стороннього сервісу. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
31 
Змн. Арк. № докум. Підпис Дата  
РОЗДІЛ 3 
 
РЕАЛІЗАЦІЯ, НАЛАШТУВАННЯ ТА ТЕСТУВАННЯ СИСТЕМИ 
ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ 
 
3.1. Налаштування апаратних компонент системи 
 
Для створення повноцінної системи інформування про інциденти 
фізичної безпеки та при підключенні окремих датчиків, компонент для роботи 
по технології в рамках даної системи необхідно провести налаштування 
мікроконтролера та мережевих інтерфейсів.  
Центральний контролер СІІФД перш за все має вбудований Wi-Fi 
адаптер, а також програмне забезпечення, що дозволяє здійснювати передачу 
і обмін даними між фізичним світом і комп'ютерними системами в 
автоматичному режимі, за допомогою використання стандартних протоколів 
зв’язку. 
Для реалізації зв’язку з back-end частиною в якості технології мережевої 
взаємодії використано технологію Ethernet, а в якості протоколу IP, TCP, 
DHCP, HTTP тощо. Сама концепція взаємодії окремих частин базується на 
основі базової еталонної моделі взаємодії відкритих систем – OSI [16].  
 
3.2. Вибір середовища розробки та програмування 
мікроконтролера системи 
 
Для реалізації СІІФД обраний контролер Arduino оснащений адаптером 
для підключення до локальних мереж типу Ethernet. Як правило, таке 
підключення відбувається через Wi-Fi-інтерфейс, яким оснащений МК 
NodeMCU. Він використовується з різними дизайном елементів на платі. 
Для програмування, відлагодження та завантаження програмного коду 
до контролера ССІФД необхідно обрати середовище розробки. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
32 
Змн. Арк. № докум. Підпис Дата  
3.2.1 Середовища розробки для апаратної частини системи 
Для розробки проектів з використанням Arduino-сумісних контролерів 
можна обрати серед таких рішень: 
− Arduino IDE 
− Programino; 
− B4R; 
− CodeBlocks for Arduino. 
Кожне з даних середовищ має свої переваги і недоліки, але для 
виконання даного проекту зупинимо свій вибір на ПЗ Arduino IDE. Це 
офіційно рекомендоване середовище розробки, яке інтегроване в різноманітні 
програмні засоби, пов’язані з Arduino. Воно має профілі для роботи з усіма 
офіційними Arduino-платами. 
 
3.2.2 Arduino IDE – це інтегроване середовище розробки для Windows, 
MacOS та Linux, розроблене на Сі та C++, призначене для створення та 
завантаження програм на Arduino-сумісні плати, а також на плати інших 
виробників. 
Зовнішній вид середовища Arduino IDE з фрагментом програми для 
мікроконтролера СІІФД наведений на Рис.3.1. 
Дане середовище розробки відрізняється простотою і функціональністю 
для створення власного ПЗ. З'єднання ПК із мікроконтролером при роботі з 
Arduino IDE реалізується через інтерфейс USB. Код можна писати Сі-
подібною мовою. Він пишеться в редакторі, в якому реалізовано підсвічування 
команд та спелчекер. 
Дане середовище розробки програмного забезпечення (IDE) призначено 
для конструктів на основі плат Arduino з'явилося одночасно з апаратною 
частиною платформи.  
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
33 
Змн. Арк. № докум. Підпис Дата  
 
 
Рис.3.1. – Зовнішній вид середовища Arduino IDE 
 
Низький поріг входження у конструювання своїх електронних пристроїв 
досягається з допомогою простоти написання програмної частини. У кожен 
мікроконтролер вшитий завантажувач, який трансформує інструкції, написані 
людиною, в машинні коди без використання апаратного програматора [15]. 
Розробники-початківці та досвідчені інженери з розробки електронних 
пристроїв цінують легкість, з якою створюється працюючий прототип або 
готовий пристрій. Для роботи з апаратурою потрібен лише комп'ютер із 
встановленим середовищем розробки, яке вільно поширюється [15]. 
 
3.2.3 Налаштування та робота з пристроєм передачі даних WiFi NodeMCU 
CH340G та з хмарним сервером для IoT 
Розглянемо далі технологію встановлення та реалізації підключення на 
базі такого адаптеру – плату Wi-Fi пристрою NodeMCU. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
34 
Змн. Арк. № докум. Підпис Дата  
NodeMCU (Lolin) являє собою плату розробника на базі чіпа ESP8266 
(версія ESP12E), який являє собою UART-WiFi модуль з ультра низьким 
споживанням [25]. Сам чіп проектувався для роботи в складі систем інтернет 
речей - Internet of Things (IoT). Розробники даної плати дотримувалися підходу 
при проектуванні, який дозволяє спростити розробку, тому що на ній вже 
реалізовано підключення по USB, регулятор живлення і всі виводи чіпа 
розведені на гребінки зі стандартним кроком 2.54 мм, що дозволяє вставити 
його в макетну плату і створити прототип навіть не використовуючи паяльник. 
Крім цього така плата поставляється з прошивкою NodeMCU, що дозволяє 
програмувати її за допомогою мови Lua або за допомогою вбудованих в 
середовище розробки Arduino IDE мов. 
Розглянемо налаштування мережевого інтерфейсу для системи IoT на 
базі плати NodeMCU. З підключеним живленням виглядає вона так (Рис. 3.2). 
 
 
 
Рис. 3.2. – Зовнішній вигляд спеціалізованого комп’ютера ESP 8266 з 
модулем Wi-Fi 
 
Основні технічні характеристики Arduino-сумісного спеціалізованого 
комп’ютера Node MCU ESP 8266 з модулем WiFi: 
− Мережевий інтерфейс WiFi 802.11 b / g / n; 
− підтримка STA / AP / STA + AP режимів; 
− вбудований стек протоколів TCP/IP з підтримкою множинних 
клієнтських підключень (до 5); 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
35 
Змн. Арк. № докум. Підпис Дата  
− D0 - D8, SD1 - SD3: можуть бути використані як GPIO, PWM, 
IIC, тощо; 
− ток на виведення: 15 мА; 
− AD0: 1 виведення АЦП; 
− живлення: 4.5 - 9В (10В максимум), живлення від USB з 
наданням отладочного інтерфейсу; 
− споживання: обмін даними: ~ 70 мА (200 мА максимум), 
очікування: <200 мкА; 
− швидкість передачі: 110-460800 б/сек; 
− підтримка UART / GPIO інтерфейсів передачі даних; 
− перепрошивка з хмари або через USB; 
− відстань між контактними пінами: 28 мм; 
− діапазон робочих температур: -40 ~ +125 ° C; 
− об’єм флеш - пам’яті – до 4Мб; 
− тактова частота мікропроцесорного ядра МК – 80 МГц 
(максимально, до 160 МГц). 
По суті, NodeMCU є платою, на якій розміщені: сам модуль ESP-8266, 
стабілізатор напруги і USB-UART міст. 
Плата NodeMcuV2 яка розроблялася для «Інтернет речей» (IoT), по суті 
дана плата може зв'язати фізичний об'єкт (реле, датчики і так далі) з 
інтернетом. Зараз це одне з найпопулярніших напрямків у сфері технологій 
IoT та «Розумний дім». 
При необхідності програмувати плату необхідно здійснити ряд заходів 
[20]: 
1. Перевірити чи встановлені драйвери на пристрій – спеціальний 
комп’ютер ESP 8266. В середовищі ОС Windows це робиться так, як показано 
на Рис. 3.3. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
36 
Змн. Арк. № докум. Підпис Дата  
 
Рис. 3.3. – Перевірка встановлених драйверів для роботи зі спеціальним 
комп’ютером NodeMCU 
 
2. Далі встановлюємо необхідну швидкість передавання даних – 
наприклад: 115200 біт/с (Рис. 3.4). 
У налаштуваннях наявні і інші швидкості передавання даних через 
UART-лінії, але вони мають менші від 115200 значення. 
 
 
 
Рис. 3.4. – Встановлення швидкості передавання даних 
для комунікації з NodeMCU 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
37 
Змн. Арк. № докум. Підпис Дата  
3. Далі приступаємо до програмування даного пристрою. Для цього 
відкриваємо пункт «Настройки» середовища Arduino IDE, де встановлюємо в 
п. «Дополнительные ссылки для менеджера плат» посилання на json-
специфікацію бібліотеки даної плати ESP 8266 та місце розміщення скетчів, 
які будуть розроблятися до неї (Рис. 3.5). 
 
 
Рис. 3.5. – Встановлення посилання на json-специфікацію бібліотеки даної 
плати ESP 8266 та місце розміщення скетчів 
 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
38 
Змн. Арк. № докум. Підпис Дата  
4. Налаштування «Менеджера плат». Для виконання даного кроку 
заходимо в меню «Инструменты» Arduino IDE де обираємо пункт» 
«Менеджера плат», де знаходимо плату ESP8266, яку необхідно встановити 
для можливості роботи з нею в середовищі (кнопка «Установки», Рис. 3.6). 
 
Рис. 3.6. – Встановлення необхідних програмних бібліотек для роботи з 
менеджером ESP 8266 
 
Наразі, актуальна версія ПЗ для роботи з платою – 2.7.4. В результаті 
будуть завантажені інструментальні засоби для роботи з даною платою (Рис. 
3.7). 
 
Рис. 3.7. – Завантаження інструментальних засобів для роботи з платою 
NodeMCU 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
39 
Змн. Арк. № докум. Підпис Дата  
Після завантаження, в меню «Инструменты» Arduino IDE бачимо 
наступний перелік доступних для програмування в середовищі Arduino IDE 
версій спеціального комп’ютера ESP 8266 (Рис. 3.8). 
 
 
Рис. 3.8. – Вибір версії плати ESP 8266 в середовищі Arduino IDE 
 
5. Вибір плати та перевірки її налаштувань. Далі обираємо плату та 
її налаштування, які будемо використовувати для подальшої роботи в 
середовищі розробки Arduino IDE. Після чого основні системні специфікації 
плати ESP 8266 з’являться в меню «Инструменты» (Рис. 3.9). 
 
 
 
Рис. 3.9. – Основна системна специфікації плати NodeMCU 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
40 
Змн. Арк. № докум. Підпис Дата  
Для подальшої роботи з платою NodeMCUI можна залишити 
налаштування плати за замовченням. 
Технічні параметри мережевого адаптера даної плати наступні: 
− Напруга живлення: 5 В (от USB); 
− максимальний стурм: 220 мА; 
− версія модуля ESP8266: ESP-12E; 
− підтримка Wi-Fi протоколів: 802.11 b / g / n;  
− підтримка режимів маршрутизації: WiFi Direct (P2P), soft-AP 
(точка доступа); 
− тип антени: PCB-антена 3dBi; 
− вбудований стек протоколів: TCP / IP; 
− габарити: 49 мм x 24.5 мм x 13 мм. 
 
3.3. Організація взаємодії компонентів системи інформування 
 
 Дану роботу виконано з використанням Телеграм бота. Датчик 
при реагуванні на рух відправляє сигнал на чіп CH340G мікроконтролера 
NodeMCU, а той в свою чергу відправляє повідомлення на бота який 
повідомляє на телефоні/ноутбуці про рух. 
Схема взаємодії апаратних елементів СІІФД наведено на Рис.3.10. 
 
 
Рис. 3.10. – Схема взаємодії апаратних елементів СІІФД 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
41 
Змн. Арк. № докум. Підпис Дата  
З метою найбільш якісного охоплення всіх можливих точок порушення 
фізичного доступу до контролера СІІФД підключено 4 ІЧ-датчика присутності 
– по два на кожному незалежному контурі. Схема їх під’єднання до контролера 
наведена на Рис.3.11. 
 
 
 
Рис. 3.11. – Схема під’єднання 4-х ІЧ-датчика присутності (по 2 на кожному 
контурі) до контролера NodeMCU 
  
Після створення апаратної частини системи переходимо до розробки 
компонент програмного коду для СІІФД. 
 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
42 
Змн. Арк. № докум. Підпис Дата  
3.4. Програмне забезпечення системи інформування про 
інциденти 
 
3.4.1 Розробка серверної частини системи 
Код бекенда бота написаний на мові С#, за допомогою технології 
AngleSharp. 
Програмний код серверної частини бота неведений в додатку А. В якості 
середовища розробки використовується Microsoft Visual Studio. 
Програмний код складається з класу class Program. Для реалізації 
повного функціоналу боту СІІФД даний клас містить 3 методи: 
− Private void Run(). Ініціалізує створений бот і запускає процес 
прослуховування ним повідомлень від сторін СІІФД; 
− private async void BotOnUpdate() реалізує методи реагування на 
події, що надходять до бота та оброблюються ним в частині інцидентів 
фізичного доступу; 
− private async void BotOnMessageReceived() реалізує процес 
відправлення повідомлень з врахуванням джерела виникнення таких 
інцидентів. 
Для написання серверної частини бота були використані сторонні класи, 
в якій містяться функції для реалізації телеграм бота, зокрема класи: 
− Telegram.Bot; 
− Telegram.Bot.Args; 
− Telegram.Bot.Types.Enums; 
− Telegram.Bot.Types.InlineQueryResults; 
− Telegram.Bot.Types.InputFiles; 
− Telegram.Bot.Types.ReplyMarkups. 
А також простір імен для телеграм бота - TelegramBot.Example. Всі 
перераховані сторонні класи та простір імен є складовою частиною Telegram 
Bot SDK API ПЗ для розробників Telegram ботів. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
43 
Змн. Арк. № докум. Підпис Дата  
3.4.2 Програми для центрального контролера СІІФД 
Перш за все в програмний код для контролера NodeMCU СІІФД 
імпортуємо необхідні для роботи з W-Fi адаптером, API Telegram та 
платформою Arduino бібліотеки: 
 
#include <ESP8266WiFi.h> 
#include <WiFiClientSecure.h> 
#include <UniversalTelegramBot.h> 
#include <ArduinoJson.h> 
 
В кожному конкретному випадку для під’єднання до Internet через Wi-
Fi інтерфейс контролера необхідно вказувати параметри авторизації для точки 
доступу: 
 
const char* ssid = " ***** "; //назва мережі 
const char* password = "***** ";// пароль до мережі 
 
Також для доступу до серверної частини бота вказуємо авторизаційні 
дані токена Telegram бота (доступ до API сервера): 
 
#define BOTtoken "1787193421:AAGQ-
eOvn5zRQG8tt8tGCydghgbYuI_faO4*" 
 
Також вказуємо ідентифікатор користувача (адміністратора системи), 
кому у аккаунт Telegram будуть надходити повідомлення про спрацьовування 
датчиків ССІФД: 
 
#define CHAT_ID " 594613589*0" 
 
Створюємо новий екземпляр класу WiFiClientSecure (створення нового 
Wi-Fi клієнту): 
 
WiFiClientSecure client;  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
44 
Змн. Арк. № докум. Підпис Дата  
Вказуємо порт ІЧ датчика присутності (hc rc501): 
 
const int motionSensor = 14; 
 
Ініціалізація Wi-Fi і підключення ESP8266 до локальної мережі дані якої 
вказані раніше: 
 
WiFi.mode(WIFI_STA); 
WiFi.begin(ssid, password); 
while (WiFi.status() != WL_CONNECTED) { 
  delay(1000); 
  Serial.println("Connecting to WiFi.."); 
} 
 
Реалізуємо відправлення повідомлення контролером NodeMCU, для 
того, щоб проінформувати користувача (адміністратора СІІФД) про те,  що бот 
запустився: 
 
bot.sendMessage(CHAT_ID, "Bot started up", ""); 
 
Змінюємо зміст стандартної функції скетча Arduino контролера 
NodeMCU для того, щоб при виявлені руху відправлялося повідомлення про 
факт виявлення руху: 
 
void loop() { 
  if(motionDetected){ 
    bot.sendMessage(CHAT_ID, "Motion detected!!", ""); 
    Serial.println("Motion Detected"); 
    motionDetected = false; 
  } 
} 
 
Повний текст програми (скетча) для головного контролера системи 
інформування про інциденти фізичного доступу наведений в додатку Б. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
45 
Змн. Арк. № докум. Підпис Дата  
3.5. Створення бота 
 
Способи отримання chat id [15, 16]. 
1. Додаємо в список контактів бота @MyTelegramID_bot (Рис. 3.12). 
 
 
 
Рис. 3.12. – Додавання в список контактів бота 
 
2. Починаємо діалог з даним ботом командою /start. У відповіді від 
бота отримуємо цифри ідентифікатора, який нас цікавить (Рис. 3.13); 
3. Можна також використати бота @GetMyIDBot або @my_id_bot 
для отримання chat id; 
4. Дістати chat id можна також за допомогою сторонніх ресурсів, на 
зразок сервісу cmsru/kak-poluchit-chat-id-telegram/. Для цього потрібно 
відправити будь-яке повідомлення своєму боту і вказати bot token у 
відповідному полі. 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
46 
Змн. Арк. № докум. Підпис Дата  
 
 
Рис. 3.13. – Отримання від мастер бота chat id 
 
5. Можна скористатися методом getUpdates () для отримання ID чату. 
Для прив'язки бота API до свого облікового запису, створюючи його, слід 
скопіювати ключ-токен, який надішле Botfather. Потім необхідно написати 
перше повідомлення своєму роботу, ID генерується під час його відправлення. 
Далі прописується в адресному рядку браузера посилання: 
https://api.telegram.org/bot<token>/getUpdates, де <token> – це персональний 
ключ. Якщо запит відправлено правильно, після всіх маніпуляцій у відповідь 
надійде масив, що містить необхідний ID. Коли ідентифікатор отримано, 
можна продовжувати подальшу роботу з ним, наприклад, спробувавши 
відправити собі повідомлення, скориставшись методом sendMessage. 
Отримавши ID бота можна, підставити всі необхідні дані в створюваний скетч 
Arduino, включаючи ідентифікаційні та авторизаційні параметри точки 
доступу до мережі Internet [15,16].  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
47 
Змн. Арк. № докум. Підпис Дата  
3.5.1 Алгоритм створення Telegram Bot  
Спочатку знаходимо“ botfather ” і натискаємо BotFather (Рис. 3.14) 
 
 
Рис. 3.14. – Запуск майстер-бота Telegram - BotFather 
 
 За допомогою дії, наведеної на Рис. 3.14 створюємо персонального бота 
на пристрої оператора(адміністратора), на який будуть надходити 
повідомлення про настання того чи іншого інциденту фізичного доступу. 
Відповідно до кількості підключених до мікроконтролера СІІФД, може 
надходити максимум 4 різних повідомлення про спрацювання: 
− «1.1» при спрацьовуванні 1 датчика першого апаратного 
контуру підключення СІІФД; 
− «1.2» при спрацьовуванні 2 датчика першого апаратного 
контуру підключення СІІФД; 
− «2.1» при спрацьовуванні 1 датчика другого апаратного контуру 
підключення СІІФД; 
− «2.2» при спрацьовуванні 2 датчика другого апаратного контуру 
підключення СІІФД; 
У випадку необхідності до контролера NodeMCU СІІФД можна 
підключити датчики реагування на інциденти, які працюють за іншим 
принципом (наприклад, будь-який з наведених на Рис. 2.2). При цьому не буде 
необхідності змінювати програмний код серверної частини telegram-бота або 
програму для центрального контролера СІІФД чи створювати іншого бота. 
Достатньо буде лише під’єднати нові датчики до аналогічних апаратних ліній 
контролера NodeMCU. Єдиною вимогою буде те, що виводи нових датчиків 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
48 
Змн. Арк. № докум. Підпис Дата  
повинні теж бути дискретними (підключати до портів, позначених, як D0, D1, 
D2, D3 і т.д.). 
У наступному вікні запускаємо створення нашого боту за допомогою 
кнопки старт (Рис. 3.15). 
 
Рис. 3.15. – Процес створення нового бота для СІІФД за допомогою майстер 
бота Telegram - BotFather 
 
Для безпосереднього створення telegram-бота використовуємо наступні 
дії (команду) /newbot . 
Назва боту його ідентифікатор для загального користування. Після 
успішного створення нам був виданий маркер нашого боту (Рис.3.16). 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
49 
Змн. Арк. № докум. Підпис Дата  
 
Рис. 3.16. – Отриманий в результаті створення боту унікальний персональний 
маркер боту 
 
Даний маркер потрібен для одного з етапів підключення бота до модуля  
Наступний етап – це створення ідентифікатора чату для цього в 
Телеграмі знаходимо IDBot та розпочинаємо з ним чат (Рис. 3.17). 
 
 
 
Рис. 3.17. – Створення ідентифікатору чату повідомлень про інциденти 
фізичного доступу для створеного бота СІІФД 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
50 
Змн. Арк. № докум. Підпис Дата  
Для початку чату вводимо команду /getid та отримуємо власний 
ідентифікатор чату в telegram, який також потрібен для з’єднання модуля та 
бота.  
 
3.6. Тестування системи 
 
Після успішного підключення всіх апаратних частин, компіляції всіх 
програмних компонент створеної СІІФД, створення нового бота та нового чату 
у користувача (адміністратора) СІІФД можна приступити до тестування 
системи.  
При запуску СІІФД бачимо старт і ініціалізацію створеного telegram-
бота (Рис.3.18). 
 
 
Рис. 3.18. – Назва створеного боту користувача, призначеного для 
відображення повідомлень порушення фізичної безпеки 
 
Для тестування необхідно ініціювати подію порушення фізичного 
доступу (інцидент). Для цього активуємо один з 4 датчиків, підключених до 
контролера NodeMCU. В результаті бачимо наступне повідомлення в 
створеному чаті нового боту (названого «бот») (Рис. 3.19). 
 
 
 
Рис. 3.19. – Повідомлення про зафіксований інцидент (появу руху об’єкту в 
зоні відповідальності датчика СІІФД) 
 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
51 
Змн. Арк. № докум. Підпис Дата  
Отже, створена СІІФД працює і успішно виконує заплановані функції з 
інформування про інциденти фізичного доступу до об’єкту охорони. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
52 
Змн. Арк. № докум. Підпис Дата  
ЗАГАЛЬНІ ВИСНОВКИ 
 
В результаті проведеного в роботі дослідження, присвяченого аналізу, 
концептуальної будови, синтезу, ролі та місця системи інформування про 
інциденти фізичної доступу на базі сервісів соціальних мереж з 
використанням мікроконтролерів було: 
− Проаналізовано роль і місце систем інформування про інциденти 
фізичного доступу в складі КСЗІ та нормативні документи, щодо їх функцій 
та складу; 
− розроблено структуру системи інформування та алгоритм її 
роботи, створене схемотехнічне рішення та апаратні компоненти 
(мікроконтролер, датчик) та сформовано логіку їх взаємодії;  
− створено програмний код окремого для серверної частини 
telegram-бота, мікроконтролера NodeMCU, створений та налаштований 
telegram-бот (API для доступу до сервера), організований персональний чат 
для інформування оператора (адміністратора СІІФД) про настання 
інцидентів; 
− створену систему налаштовано та протестовано на 
функціональність. 
Проведені в результаті виконання роботи дослідження показують 
адекватность створеної системи стандартам відповідності стандарту 
управління інформаційною безпекою ISO/IEC 27001. 
  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
53 
Змн. Арк. № докум. Підпис Дата  
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
 
1. Марков Г. А. Вопросы физической безопасности / Георгий 
Алексеевич Марков. // Вопросы кибербезопасности. – 2015. – №4. – С. 70–76. 
Режим доступу: https://cyberleninka.ru/article/n/voprosy-fizicheskoy-
bezopasnosti-informatsii/viewer 
2. ДСТУ ISO / IEC 27001-2006 «Інформаційна технологія. Методи і 
засоби забезпечення безпеки. Системи менеджменту інформаційної безпеки. 
Вимоги» [Електронний ресурс] // Інформаційна безпека. – 2019. – Режим 
доступу до ресурсу: 
https://stud.com.ua/179795/informatika/dstu_27001_2006_informatsiyna_tehnolog
iya_metodi_zasobi_zabezpechennya_bezpeki_sistemi_menedzhmentu_infor. 
3. Постанова КМУ. "Про затвердження Загальних вимог до 
кіберзахисту об’єктів критичної інфраструктури". // Верховна Рада України. – 
2019. – №518. 
4. Система обнаружения вторжений и нарушения периметра 
[Електронний ресурс] // RCI Consulting. – 2021. – Режим доступу до ресурсу: 
https://rci-c.com/ru/technology/systema-obnaruzhenyia-vtorzhenyj/.  
5. Системы охраны периметра [Електронний ресурс] // ВалТек. – 
2020. – Режим доступу до ресурсу: https://valtek.com.ua/ru/system-
integration/security-control-system/integrated-security-systems/perimeter-security-
systems. 
6. Черкасов В. Иновационный ревизор / Вячеслав Черкасов. // 
Бизнес-журнал. – 2013. – №12. – С. XV. 
7. Система сбора и обработки информации [Електронний ресурс] // 
IDMatic. Системы контроля доступа. – 2021. – Режим доступу до ресурсу: 
http://idmatic.ru/sistema-sbora-obrabotki-informacii/84-sistema-sbora-obrabotki-
informacii/172-sbor-obrabotka-informacii.  
8. Система защиты компьютерных сетей и помещений от 
несанкционированного доступа на базе ActiveIdentity компании HID 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
54 
Змн. Арк. № докум. Підпис Дата  
[Електронний ресурс] // АРМО-СИСТЕМЫ. – 2021. – Режим доступу до 
ресурсу: https://www.armosystems.ru/articles/hid_skd/log_dostup/computer-
network-protection/. 
9. Умный Дом — охрана и безопасность. [Електронний ресурс] // 
Свойства. – 2021. – Режим доступу до ресурсу: https://smarton.com.ua/novosti-
umnogo-doma/tpost/17dj1sdmd1-umnii-dom-ohrana-i-bezopasnost. 
10. Отмена КСЗИ - прорыв или пиррова победа? [Електронний ресурс] 
// Интерфакс-Украина. – 2020. – Режим доступу до ресурсу: 
https://interfax.com.ua/news/blog/677433.html. 
11. Анализ рынка информационной безопасности в России и СНГ. 
Часть 4. [Електронний ресурс] // ООО "АМ Медиа". – 2019. – Режим доступу 
до ресурсу: https://www.anti-malware.ru/analytics/Market_Analysis/analysis-
information-security-market-russia-part-4. 
12. Дорофеев А. В. Менеджмент информационной безопасности: 
основные концепции / А. В. Дорофеев, А. С. Марков. // Вопросы 
кибербезопасности. – 2014. – №1. – С. 67–73. Режим доступу: 
https://cyberleninka.ru/article/n/menedzhment-informatsionnoy-bezopasnosti-
osnovnye-kontseptsii/viewer 
13. Дорофеев А. В. Менеджмент информационной безопасности: 
переход на ISO 27001:2013 / Александр Владимирович Дорофеев. // Вопросы 
кибербезопасности. – 2014. – №3. – С. 69–73. Режим доступу: 
https://cyberleninka.ru/article/n/menedzhment-informatsionnoy-bezopasnosti-
perehod-na-iso-27001-2013/viewer 
14. НД ТЗІ 2.5-005-99. «Класифікація автоматизованих систем і 
стандартні функціональні профілі захищеності оброблюваної інформації від 
несанкціонованого доступу». ДСТСЗІ СБ України. Київ. 1999. – 16 с.  
15. Спеціалізовані комп’ютери: навчальний посібник/ Сагун А.В., 
Лахно В.А, Бобков В.Б., Касаткін Д.Ю, Хайдуров В.В. – Київ : НУБіП України, 
2021. – 217 с. 
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
55 
Змн. Арк. № докум. Підпис Дата  
16. Комп'ютерні мережі: [навчальний посібник] / А. Г. Микитишин, 
М. М. Митник, П. Д. Стухляк, В. В. Пасічник. — Львів: «Магнолія 2006», 2013. 
— 256 с. ISBN 978-617-574-087-3. 
17. Как получить Chat ID Телеграм? [Електронний ресурс] // CMS3. – 
2021. – Режим доступу до ресурсу: https://cms3.ru/kak-poluchit-chat-id-
telegram/.  
А рк. 
 ЧДТУ.21.20100.003 ПЗ 
56 
Змн. Арк. № докум. Підпис Дата  
ДОДАТОК А – ПРОГРАМНИЙ КОД СЕРВЕРНОЇ ЧАСТИНИ 
ТЕЛЕГРАМ БОТУ СИСТЕМИ ОПОВІЩЕННЯ ПРО ІНЦИДЕНТИ 
ФІЗИЧНОЇ БЕЗПЕКИ 
 
using System; 
using System.IO; 
using System.Linq; 
using System.Threading.Tasks; 
using Telegram.Bot; 
using Telegram.Bot.Args; 
using Telegram.Bot.Types.Enums; 
using Telegram.Bot.Types.InlineQueryResults; 
using Telegram.Bot.Types.InputFiles; 
using Telegram.Bot.Types.ReplyMarkups; 
namespace TelegramBot.Example 
{ 
 
class Program 
{ 
private static Program _program; 
private readonly TelegramBotClient _bot = new 
TelegramBotClient("/*Інформація виду: id:botcode*/"); 
 
static void Main(string[] args) 
{ 
_program = new Program(); 
_program.Run(args); 
} 
 
private void Run(string[] args) 
{ 
_bot.OnMessage += BotOnMessageReceived; 
_bot.OnMessageEdited += BotOnMessageReceived; 
_bot.OnCallbackQuery += BotOnCallbackQueryReceived; 
_bot.OnInlineQuery += BotOnInlineQueryReceived; 
_bot.OnInlineResultChosen += BotOnChosenInlineResultReceived; 
_bot.OnReceiveError += BotOnReceiveError; 
_bot.OnUpdate += BotOnUpdate; 
var me = _bot.GetMeAsync().Result; 
Console.Title = me.Username; 
_bot.StartReceiving(); 
Console.WriteLine($"Start listening for @{me.Username}"); 
Console.ReadLine(); 
_bot.StopReceiving(); 
} 
 
private async void BotOnUpdate(object sender, UpdateEventArgs e) 
{ 
switch (e.Update.Type) 
{ 
 
 
case UpdateType.Unknown: 
break; 
case UpdateType.Message: 
break; 
case UpdateType.InlineQuery: 
break; 
case UpdateType.ChosenInlineResult: 
break; 
case UpdateType.CallbackQuery: 
Console.WriteLine(e.Update.CallbackQuery.Data); 
try 
{ 
await _bot.SendTextMessageAsync( 
e.Update.CallbackQuery.Message.Chat.Id, 
$"Your choice is:  
{e.Update.CallbackQuery.Data}"); 
} 
catch (Exception ex) 
{ 
Console.WriteLine(ex); 
} 
break; 
case UpdateType.EditedMessage: 
break; 
case UpdateType.ChannelPost: 
break; 
case UpdateType.EditedChannelPost: 
break; 
case UpdateType.ShippingQuery: 
break; 
case UpdateType.PreCheckoutQuery: 
break; 
default: 
Console.WriteLine(e.Update); 
break; 
} 
} 
 
private async void BotOnMessageReceived(object sender, 
MessageEventArgs e) 
{ 
var message = e.Message; 
if (message == null || message.Type != MessageType.Text) return; 
try 
{ 
switch (message.Text.Split(' ').First()) 
{ 
case "/inline": 
await _bot.SendChatActionAsync(message.Chat.Id,  
ChatAction.Typing); 
await Task.Delay(500); 
var inlineKeyboard = new InlineKeyboardMarkup(new[] 
{ 
 
 
new [] 
{ 
InlineKeyboardButton.WithCallbackData("1.1"), 
InlineKeyboardButton.WithCallbackData("1.2"), 
}, 
new [] 
{ 
InlineKeyboardButton.WithCallbackData("2.1"), 
InlineKeyboardButton.WithCallbackData("2.2"), 
} 
}); 
await _bot.SendTextMessageAsync( 
message.Chat.Id, 
"Motion detected !!", 
replyMarkup: inlineKeyboard); 
break; 
} 
  
 
 
ДОДАТОК Б - ПОВНИЙ ТЕКСТ ПРОГРАМИ ГОЛОВНОГО 
КОНТРОЛЕРА СИСТЕМИ ІНФОРМУВАННЯ ПРО ІНЦИДЕНТИ 
ФІЗИЧНОГО ДОСТУПУ 
 
#include <ESP8266WiFi.h> 
#include <WiFiClientSecure.h> 
#include <UniversalTelegramBot.h> 
#include <ArduinoJson.h> 
 
const char* ssid = "Korotash";// ім’я мережі WiFi 
const char* password = "1Q2w3E4r5T"; 
 
#define BOTtoken " 1787193421:AAGQ-
eOvn5zRQG8tt8tGCydghgbYuI_faO4 "   
#define CHAT_ID " 594613589" 
 
X509List cert(TELEGRAM_CERTIFICATE_ROOT); 
WiFiClientSecure client; 
UniversalTelegramBot bot(BOTtoken, client); 
 
const int motionSensor = 14;  
bool motionDetected = false; 
 
void ICACHE_RAM_ATTR detectsMovement() { 
    motionDetected = true; 
} 
 
void setup() { 
  Serial.begin(115200); 
  configTime(0, 0, "pool.ntp.org");       
  client.setTrustAnchors(&cert);  
 
    pinMode(motionSensor, INPUT_PULLUP); 
  attachInterrupt(digitalPinToInterrupt(motionSensor), 
detectsMovement, RISING); 
 
    Serial.print("Connecting Wifi: "); 
  Serial.println(ssid); 
 
  WiFi.mode(WIFI_STA); 
  WiFi.begin(ssid, password); 
 
  while (WiFi.status() != WL_CONNECTED) { 
    Serial.print("."); 
    delay(500); 
  } 
 
  Serial.println(""); 
  Serial.println("WiFi connected"); 
  Serial.print("IP address: "); 
 
 
  Serial.println(WiFi.localIP()); 
 
  bot.sendMessage(CHAT_ID, "Bot started up", ""); 
} 
 
void loop() { 
  if(motionDetected){ 
    bot.sendMessage(CHAT_ID, "Motion detected!!", ""); 
    Serial.println("Motion Detected"); 
    motionDetected = false; 
  } 
} 
  
 
 
ДОДАТОК Г – ПРЕЗЕНТАЦІЯ ДО КВАЛІФІКАЦІЙНОЇ РОБОТИ