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
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/7176| Title: | Структурна ідентифікація інформаційних систем розпізнавання малогабаритних об'єктів |
| Authors: | Метелап, Володимир Володимирович Строганов, Янош Романович |
| Keywords: | машинний зір;глибоке навчання;YOLO;детекція об’єктів;аугментація даних;Pytorch;OpenCV;UML;machine vision;deep learning;YOLO;object detection;data augmentation;Pytorch;OpenCV;UML |
| Issue Date: | 29-Jan-2026 |
| Abstract: | АНОТАЦІЯ
Строганов Я.Р. Структурна ідентифікація інформаційних систем розпізнавання малогабаритних об'єктів кваліфікаційна робота магістра з спеціальності 121 – «Інженерія програмного забезпечення» ЧДТУ, м.Черкаси 2025 рік.
Магістерська кваліфікаційна робота присвячена розв’язанню актуальної науково-практичної задачі – створенню програмного комплексу для детекції небезпечних об’єктів, малих об’єктів асиметричної форми. Робота фокусується на вирішенні проблеми виявлення в умовах зниженої інформативності вхідних даних, таких як маскування об'єктів та шумові перешкоди.
У роботі проведено ґрунтовний аналіз існуючих архітектур глибокого навчання, зокрема сімейства YOLO, програмні компоненти поліпшення результатів візуального аналізу зображення. Виконано повний цикл інженерного проектування програмного комплексу з використанням UML, включаючи діаграми класів, компонентів та розгортання .
Особистий внесок полягає у створенні спеціалізованого програмного комплексу з використанням ефективних методів аугментації (SAI, TTA) та розробці програмного конвеєра (pipeline) для покращення результатів використання моделі на базі PyTorch, Ultralytics та OpenCV.
В результаті експериментального тестування розроблена модель продемонструвала високу ефективність: середня точність ([email protected]) досягла 86.3% , а швидкість інференсу на цільовому GPU – ~550 мс. Практичне значення полягає в можливості застосування моделі для створення автоматизованих систем моніторингу в оборонній сфері та цивільному захисті. ANNOTATION Stroganov Y.R. Structural identification of information systems for recognizing small objects Master's thesis in the specialty 121 – “Software Engineering” Cherkasy State Technological University, Cherkasy 2025. The master's thesis is devoted to solving an urgent scientific and practical problem – the creation of a software complex for the detection of dangerous objects and small objects of asymmetrical shape. The work focuses on solving the problem of detection in conditions of reduced input data informativeness, such as object masking and noise interference. The work provides a thorough analysis of existing deep learning architectures, in particular the YOLO family, software components for improving the results of visual image analysis. A complete cycle of engineering design of the software complex using UML, including class, component, and deployment diagrams, has been completed. My personal contribution consists of creating a specialized software complex using effective augmentation methods (SAI, TTA) and developing a software pipeline to improve the results of using a model based on PyTorch, Ultralytics, and OpenCV. As a result of experimental testing, the developed model demonstrated high efficiency: the [email protected] reached 86.3%, and the inference speed on the target GPU was ~550 ms. The practical significance lies in the possibility of applying the model to create automated monitoring systems in the defense sector and civil protection. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/7176 |
| Appears in Collections: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Строганов Янош Романович.pdf Restricted Access | 5.8 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи
«магістра»
освітній рівень
на тему: Структурна ідентифікація інформаційних систем розпізнавання
малогабаритних об'єктів
Виконав: студент 2 курсу, групи МПЗ-2404
спеціальності
121 «Інженерія програмного забезпечення»
(шифр і назва напряму підготовки)
Студент Строганов Я.Р.
(прізвище та ініціали)
Керівник Метелап В.В.
(прізвище та ініціали)
Рецензент Захарова М.В.
(прізвище та ініціали)
Черкаси 2025
Черкаський державний технологічний університет
повне найменування вищого навчального закладу
Факультет інформаційних технологій і систем
Кафедра програмного забезпечення автоматизованих систем
Освітній рівень магістр
Спеціальність 121 «Інженерія програмного забезпечення»
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Зав. кафедри ПЗАС, професор
С. Голуб
«___» _______________ 2025 року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ СТУДЕНТУ
Строганов Янош Романович
(прізвище, ім’я, по батькові)
1. Тему проекту (роботи) Структурна ідентифікація інформаційних систем розпізнавання
малогабаритних об'єктів.
Керівник проекту (роботи) Метелап Володимир Володимирович к.т.н. доцент
(прізвище, ім’я , по батькові, науковий ступінь, вчене звання)
Затверджені наказом Черкаського державного технологічного університету від «07»
листопад 2025року №307/03-03
2.Строк подання студентом проекту (роботи) 16.12.2025
3. Вхідні дані до проекту (роботи)
Ноутбук на базі процесора x64 з вбудованийм графічним прискорювачем серії AMD Vega 7.
Інструментальні засоби розробки: Мова програмування Python 3.12.10, бібліотеки
комп’ютерного зору (OpenCV) та машинного навчання (PyTorch, Ultralytics).
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Розділ 1 Існуючі методи та засоби розв’язання поставлених завдань
Розділ 2 Теоретичні та експериментальні дослідження
Розділ 3.Впровадження результатів досліджень у практику проектування програмного
забезпечення інформаційних систем
Розділ 4 Розробка та тестування програмного забезпечення
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових робіт проекту);
Додаток В
6. Консультанти розділів роботи
Прізвище, ініціали та посади Підпис, дата
Розділ
консультанта Завдання видав Завдання прийняв
1
2
3
7. Дата видачі завдання 13.05.2025
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№
Назва етапів випускної роботи етапів випускної Примітки
п/п
роботи
1 Постановка задачі 13.05.2025 виконано
2 Підготовка завдання 13.05.2025 виконано
3 Погодження завдання 13.05.2025 виконано
4 Затвердження завдання 13.05.2025 виконано
Основна стадія
1 Підбір матеріалів 16.05.2025 виконано
2 Аналіз шляхів вирішення поставленої задачі 17.05.2025 виконано
3 Розрахунок основних параметрів роботи 01.06.2025 виконано
4 Вибір кінцевого варіанту проектного рішення 05.06.2025 виконано
5 Оформлення первісної редакції роботи 06.06.2025 виконано
Заключна стадія
1 Узгодження прийнятих проектних рішень з 01.09.2025 виконано
керівником
2 Оформлення пояснювальної записки роботи в 04.09.2025 виконано
кінцевій редакції
3 Попередній захист роботи 12.12.2025 виконано
4 Затвердження роботи 12.12.2025 виконано
5 Рецензування роботи 13.12.2025 виконано
6 Захист роботи 16.12.2025 виконано
Студент _____________________ Строганов Я.Р.
(підпис) (прізвище та ініціали)
Керівник проекту (роботи) _____________________ Метелап В.В.
(підпис) (прізвище та ініціали)
АНОТАЦІЯ
Строганов Я.Р. Структурна ідентифікація інформаційних систем
розпізнавання малогабаритних об'єктів кваліфікаційна робота магістра з
спеціальності 121 – «Інженерія програмного забезпечення» ЧДТУ, м.Черкаси
2025 рік.
Магістерська кваліфікаційна робота присвячена розв’язанню актуальної
науково-практичної задачі – створенню програмного комплексу для детекції
небезпечних об’єктів, малих об’єктів асиметричної форми. Робота фокусується
на вирішенні проблеми виявлення в умовах зниженої інформативності вхідних
даних, таких як маскування об'єктів та шумові перешкоди.
У роботі проведено ґрунтовний аналіз існуючих архітектур глибокого
навчання, зокрема сімейства YOLO, програмні компоненти поліпшення
результатів візуального аналізу зображення. Виконано повний цикл
інженерного проектування програмного комплексу з використанням UML,
включаючи діаграми класів, компонентів та розгортання .
Особистий внесок полягає у створенні спеціалізованого програмного
комплексу з використанням ефективних методів аугментації (SAI, TTA) та
розробці програмного конвеєра (pipeline) для покращення результатів
використання моделі на базі PyTorch, Ultralytics та OpenCV.
В результаті експериментального тестування розроблена модель
продемонструвала високу ефективність: середня точність ([email protected]) досягла
86.3% , а швидкість інференсу на цільовому GPU – ~550 мс. Практичне
значення полягає в можливості застосування моделі для створення
автоматизованих систем моніторингу в оборонній сфері та цивільному захисті.
Ключові слова: машинний зір, глибоке навчання, YOLO, детекція
об’єктів, аугментація даних, Pytorch, OpenCV, UML.
ANNOTATION
Stroganov Y.R. Structural identification of information systems for recognizing
small objects Master's thesis in the specialty 121 – “Software Engineering” Cherkasy
State Technological University, Cherkasy 2025.
The master's thesis is devoted to solving an urgent scientific and practical
problem – the creation of a software complex for the detection of dangerous objects
and small objects of asymmetrical shape. The work focuses on solving the problem of
detection in conditions of reduced input data informativeness, such as object masking
and noise interference.
The work provides a thorough analysis of existing deep learning architectures,
in particular the YOLO family, software components for improving the results of
visual image analysis. A complete cycle of engineering design of the software
complex using UML, including class, component, and deployment diagrams, has
been completed.
My personal contribution consists of creating a specialized software complex
using effective augmentation methods (SAI, TTA) and developing a software
pipeline to improve the results of using a model based on PyTorch, Ultralytics, and
OpenCV.
As a result of experimental testing, the developed model demonstrated high
efficiency: the [email protected] reached 86.3%, and the inference speed on the target GPU
was ~550 ms. The practical significance lies in the possibility of applying the model
to create automated monitoring systems in the defense sector and civil protection.
Keywords: machine vision, deep learning, YOLO, object detection, data
augmentation, Pytorch, OpenCV, UML.
ЗМІСТ
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ .................................. 7
ВСТУП ......................................................................................................................... 8
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ ................................................................................. 13
1.1 Сучасний стан проблеми дистанційного виявлення вибухонебезпечних
предметів та актуальність автоматизації ................................................................. 13
1.1.1 Класифікація та порівняльний аналіз сенсорних технологій .............. 13
1.2 Еволюція методів глибокого навчання для задач детекції об'єктів ..................... 15
1.2.1 Класичні підходи проти глибокого навчання ....................................... 16
1.2.2 Класифікація архітектур детекції: Two-Stage vs One-Stage ................. 17
1.2.3 Аналіз еволюції сімейства YOLO........................................................... 18
1.3 Проблематика впровадження ML-моделей на Edge-пристроях ........................... 19
1.3.1 Обмеження обчислювальних ресурсів та енергоспоживання ............. 19
1.4 Аналіз проблеми детекції малих об'єктів (Small Object Detection) ...................... 20
1.4.1 Визначення та статистика проблеми ...................................................... 20
1.4.2 Феномен зникнення ознак (Feature Vanishing) ...................................... 20
1.4.3 Недоліки стандартного методу Resizing ................................................ 21
Висновки до розділу ............................................................................................. 22
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ . 23
2.1 Математична модель прямого поширення сигналу (Forward Pass) ...................... 23
2.1.1 Дискретна згортка та обчислювальна складність ................................. 23
2.1.2 Функції активації в контексті поширення сигналу .............................. 24
2.2 Теоретичні засади структурного аналізу складних систем обробки даних......... 24
2.2.1 Методологія функціонального моделювання IDEF0 ........................... 25
2.2.2 Методологія моделювання потоків даних (DFD) ................................. 26
2.2.3 Синтез структурних моделей та перехід до проєктування .................. 27
2.3 Структурний аналіз архітектури YOLOv11 з точки зору інференсу ................... 28
2.3.1 Ефективність блоків C3k2 та CSP .......................................................... 28
2.3.2 Пірамідальне формування ознак (SPPF та PANet) ............................... 28
2.4 Алгоритмічні основи постобробки результатів (Post-Processing) ........................ 29
2.4.1 Декодування Anchor-Free передбачень .................................................. 29
2.4.2 Теоретичні засади фільтрації (Non-Maximum Suppression) ................. 29
2.5 Теоретичне обґрунтування методів просторової обробки зображень ................. 30
2.5.1 Формалізація методу Tiling (Slicing Aided Inference) ........................... 30
2.5.2 Трансформація координат та злиття детекцій ...................................... 31
2.6 Математична модель Test-Time Augmentation (TTA) ................................. 31
Висновки до Розділу ............................................................................................. 32
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ ............................................................................. 33
3.1 Моделювання предметної області ................................................................. 33
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області .................................................................................... 33
3.1.2 Елементи моделювання предметної області ........................................ 35
3.1.3 Робоча область моделювання ................................................................. 36
3.2 Формування та аналіз вимог ..................................................................................... 37
3.2.1 Формування вимог до програмного забезпечення. Первинні і детальні
вимоги. Вимоги замовника і розробника. Функціональні та нефункціональні
вимоги……………………………………………………………………………….37
3.2.2 Формування вимог за допомогою діаграми прецедентів..................... 46
3.2.3 Проектування логічної структури програмного
комплексу…………………………………………………………………………...48
3.2.3.1 Діаграми класів ……………………………………………………….48
3.2.3.2Діаграми пакетів………………………………………………………. 50
3.2.4Архітектурне проектування……………………………………………..51
3.2.4.1Діаграма компонентів………………………………………………… 51
3.2.4.2Розгортання програмної системи на апаратних засобах. Діаграма
розгортання………………………………………………………………………… 52
3.2.5Моделювання поведінки системи………………………………………53
3.2.5.1Діаграма діяльності……………………………………………………53
3.2.5.2Діаграма послідовності………………………………………………..54
3.2.5.3Діаграма комунікації…………………………………………………..55
3.2.5.4Діаграма скінченного автомату……………………………………….57
Висновки до розділу ........... …………………………………………………….59
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ .................................................................................................... 60
4.1Розробка програмного комплексу. ………………………………………….60
4.1.1Обґрунтування вибору засобів реалізації. .............................................. 60
4.1.2Опис структурної (функціональної) схеми……………………….……61
4.1.3Опис логічної схеми системи …………………………………………..62
4.1.4Розробка бази даних……………………………………………………..63
4.1.5Розробка інтерфейсу користувача ........................................................... 63
4.1.6Опис розробки програмних компонентів………………………………65
4.2Тестування системи ....................................................................................... .67
4.2.1Модульне тестування ................................................................................ 67
4.2.1.1 Результати точності (Precision/Recall) ...................................... 73
4.2.1.2 Візуалізація та аналіз кривих навчання .................................... 74
4.2.2Інтеграційне тестування ………………………………………………...74
4.2.2.1 Залежність FPS від режиму роботи ........................................... 77
4.2.2.2 Профілювання споживання ресурсів ........................................ 78
4.2.2.3 Аналіз методів систематизації вихідних даних ....................... 79
4.2.3Системне тестування…………………………………………………….80
4.2.3.1 Апаратна платформа (Testbed) .................................................. 82
4.2.3.2 Характеристика тестового набору даних (Dataset) .................. 83
4.2.3.3 Математичний апарат оцінки якості (Metrics) ......................... 84
4.2.3.4 Природа хибно позитивних спрацювань (False Positives) ...... 85
4.2.3.5 Природа хибно негативних спрацювань (False Negatives) ..... 85
4.2.4Приймальне тестування…………………………………………………85
4.3Приклади впровадженого програмного комплексу…………………......... 87
ВИСНОВКИ ............................................................................................................. 89
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................ 91
ДОДАТОК А ............................................................................................................. 94
ДОДАТОК Б ............................................................................................................. 96
ДОДАТОК B ........................................................................................................... 103
ЧДТУ 252496.016 ПЗ
ПЕРЕЛІК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ
Абревіатура Поястнення
БПЛА Безпілотний літальний апарат
ВНП Вибухонебезпечний предмет
CNN Convolutional Neural Network (Згорткова нейронна
мережа)
YOLO You Only Look Once (Архітектура нейронної мережі)
TTA Test-Time Augmentation (Аугментація під час
тестування)
NMS Non-Maximum Suppression (Придушення
немаксимумів)
WBF Weighted Box Fusion (Зважене злиття рамок)
FPS Frames Per Second (Кадрів за секунду)
IoU Intersection over Union (Коефіцієнт перекриття)
mAP mean Average Precision (Середня точність)
CUDA Compute Unified Device Architecture
GUI Graphical User Interface (Графічний інтерфейс
користувача)
SAI Slicing Aided Inference (Інференс із використанням
нарізки зображення)
WBF Weighted Box Fusion (Зважене злиття обмежувальних
рамок)
Dataset/Датасет Набір даних
7
ЧДТУ 252496.016 ПЗ
ВСТУП
Актуальність теми. Дана кваліфікаційна робота виконана в межах
спеціальності 121 «Інженерія програмного забезпечення». Вона демонструє
практичне застосування навичок аналізу предметної області, проектування та
розробки складних програмних систем, методів наукового пізнання для
вирішення певної задачі або проведення дослідження.
Усі експерименти базуються на відкритих даних, що гарантує прозорість
та можливість відтворення отриманих результатів.
В умовах сучасних соціальних та гуманітарних катастроф, зокрема,
проблема гуманітарного розмінування територій набула критичного значення.
Значні площі земель залишаються забрудненими небезпечними предметами, що
створює довгострокову загрозу для цивільного населення та перешкоджає
економічному відновленню регіонів. Традиційні методи розмінування, які
передбачають фізичну присутність саперів, є повільними, високовартісними та
пов'язані з високим ризиком для життя персоналу і потребують заміни або
вдосконалення.
Застосування безпілотних літальних апаратів (БПЛА) та роботизованих
платформ відкриває нові можливості для дистанційної технічної розвідки (Non-
Technical Survey). Однак, ефективність таких систем обмежується
можливостями оператора аналізувати відеопотік у реальному часі, особливо при
виявленні малогабаритних та замаскованих об'єктів, таких як протипіхотні міни
типу ПФМ-1 ("Пелюстка").
Сучасні методи комп'ютерного зору, зокрема глибокі згорткові нейронні
мережі (CNN), демонструють високу точність у задачах детекції. Проте, їх
впровадження на мобільних платформах (Edge Devices) стикається з проблемою
"апаратного голоду": обмежені обчислювальні ресурси бортових комп'ютерів не
дозволяють використовувати важкі серверні моделі. Крім того, стандартні
алгоритми попередньої обробки зображень (масштабування до фіксованого
розміру) призводять до втрати дрібних об'єктів, що є неприпустимим у задачах
розмінування.
8
ЧДТУ 252496.016 ПЗ
Одним із підходів для проведення дослідження та побудови необхідної
системи є структурна ідентифікація інформаційних систем.
Структурна ідентифікація інформаційних систем – це процес визначення
внутрішньої будови, компонентів (технічних засобів, програмного
забезпечення, персоналу) та функціональних зв'язків між ними для
забезпечення ефективного збору, зберігання та обробки даних. Вона передбачає
моделювання системи, оцінювання параметрів та аналіз взаємодії елементів, що
критично для прийняття рішень та безпеки.
Таким чином, розробка спеціалізованого програмного забезпечення, яке
забезпечує баланс між точністю виявлення дрібних об'єктів (Recall) та
швидкодією (FPS) на обладнанні загального призначення, є актуальною
науково-прикладною задачею.
Об'єктом досліджень даної роботи є процеси проектування,
конструювання і застосування програмних систем та штучного інтелекту для
виявлення малих об'єктів складної форми.
Предметом досліджень є методи та алгоритми структурної ідентифікації
інформаційних систем, нейронних мереж, програмних засобів аналізу та
перевірки результатів отриманих даних, а також стратегії апаратної адаптації
програмного забезпечення до обмежених обчислювальних ресурсів,
враховуючи вимоги до точності визначення малих об'єктів складної форми.
Мета і завдання дослідження. Метою роботи є підвищення ефективності
дистанційного виявлення малих об'єктів складної форми на фото або у
відеопотоці.
Для досягнення поставленої мети необхідно вирішити такі завдання:
1 Провести аналіз існуючих методів та програмних рішень знаходження
малих обєктів складної форми.
2 Проаналізувати існуючі математичні моделі та алгоритми покращення
детекції, зокрема метод динамічного тайлінгу (Tiling) для збереження
роздільної здатності та Test-Time Augmentation (TTA) для підвищення
стійкості до шумів.
9
ЧДТУ 252496.016 ПЗ
3 Спроектувати архітектуру програмного комплексу, що реалізує
гібридний підхід для отримання кращого результату на відміну від
відомих та забезпечує ефективне використання ресурсів CPU/GPU.
4 Виконати програмну реалізацію системи та провести
експериментальні дослідження її точності та швидкодії на апаратній
платформі без спеціалізованих прискорювачів.
Предметом досліджень є методи та алгоритми структурної оптимізації
архітектури роботи глибоких нейронних мереж, програмні засоби та способи
підготовки вхідних даних, алгоритми тайлінгу (Slicing Aided Inference) та
методи ансамблювання передбачень (Weighted Box Fusion), а також стратегії
адаптації програмного забезпечення до обмежених обчислювальних ресурсів
аппаратного забезпечення, враховуючи вимоги до швидкості та точності
визначення малих об'єктів асиметричної форми, технології та методи
проектування, конструювання і застосування програмних систем.
Методи дослідження. У роботі використано комплексний методологічний
підхід:
− методи цифрової обробки зображень – для реалізації алгоритмів
тайлінгу, аугментації та візуалізації результатів.
− методи теорії штучних нейронних мереж – для побудови та
налаштування детектора на базі архітектури YOLO.
− методи об'єктно-орієнтованого проектування – для розробки
архітектури програмного забезпечення (UML).
− методи математичної статистики – для оцінки точності (Precision,
Recall, mAP) та аналізу результатів експериментів.
Наукова новизна одержаних результатів:
Удосконалено метод детекції малих об'єктів складної форми на
зображеннях високої роздільної здатності шляхом інтеграції алгоритму
динамічного тайлінгу з механізмом Weighted Box Fusion (WBF), що, на відміну
від класичного NMS, дозволяє підвищити точність локалізації об'єктів на межах
фрагментів зображення.
10
ЧДТУ 252496.016 ПЗ
Набув подальшого розвитку підхід до оптимізації інференсу нейронних
мереж на Edge-пристроях шляхом створення адаптивного конвеєра, який
динамічно перемикається між режимами високої точності (Tiling+TTA) та
високої швидкодії (Baseline) залежно від тактичної задачі.
Практичне значення одержаних результатів.
1 Розроблено діючий програмний комплекс, який дозволяє виявляти
малі об'єкти складної форми на прикладі міни типу ПФМ-1 з
імовірністю (Recall) понад 0.84, що у 2 рази перевищує показники
базових моделей.
2 Система спроектована для роботи на загальнодоступному обладнанні
(ноутбуки середнього класу), що знижує поріг входження для
волонтерських організацій та підрозділів ДСНС.
3 Реалізовано зручний графічний інтерфейс та систему звітності
(JSON/CSV/Geo-tagging), що дозволяє інтегрувати розробку в існуючі
системи управління розмінуванням.
Особистий внесок здобувача. Усі результати, наведені в кваліфікаційній
роботі, отримані автором самостійно. Автором проведено аналіз предметної
області, обґрунтовано вибір технологічного стеку, розроблено архітектуру та
програмний код системи, створено розмічений датасет та проведено
експериментальні дослідження.
Структура та обсяг роботи. кваліфікаційнійна робота складається зі
вступу, чотирьох розділів, висновків, списку використаних джерел та додатків.
У першому розділі проведено аналіз сучасного стану проблеми,
порівняння сенсорів та методів детекції, виявлено проблему "зникнення" малих
об'єктів.
У другому розділі наведено теоретичні основи функціонування
згорткових мереж, математичний опис алгоритмів тайлінгу та метрик оцінки
якості.
У третьому розділі описано проектування архітектури системи (UML-
діаграми) та програмну реалізацію ключових алгоритмів.
11
ЧДТУ 252496.016 ПЗ
У четвертому розділі представлено результати експериментальних
досліджень ефективності системи на реальному обладнанні.
12
ЧДТУ 252496.016 ПЗ
РОЗДІЛ 1 ІСНУЮЧІ МЕТОДИ ТА ЗАСОБИ РОЗВ’ЯЗАННЯ
ПОСТАВЛЕНИХ ЗАВДАНЬ
1.1 Сучасний стан проблеми дистанційного виявлення
вибухонебезпечних предметів та актуальність автоматизації
В умовах сучасних збройних конфліктів та техногенних катастроф
проблема забруднення територій вибухонебезпечними предметами (ВНП)
набуває критичного масштабу. Традиційні методи розмінування, які
передбачають безпосередню участь людини-сапера (manual demining),
характеризуються високим ризиком для життя персоналу, низькою швидкістю
обстеження територій та значною вартістю робіт. За статистичними даними
міжнародних організацій, один день активних бойових дій може призводити до
необхідності проведення робіт з розмінування протягом місяця або навіть
більше.
У цьому контексті автоматизація процесів розвідки та детекції стає не
просто технічною інновацією, а гуманітарною необхідністю. Використання
безпілотних літальних апаратів (БПЛА) дозволяє перенести сенсори
безпосередньо в зону ризику, залишаючи оператора на безпечній відстані.
Проте, сам по собі дрон – це лише носій (платформа). Ефективність системи
визначається комплексом сенсорів та алгоритмів обробки даних, здатних
ідентифікувати загрозу на фоні складного ландшафту (висока трава, сміття,
пересічена місцевість та інше).
1.1.1 Класифікація та порівняльний аналіз сенсорних технологій
Для вирішення задачі дистанційного зондування поверхні з метою
пошуку ВНП застосовується широкий спектр фізичних принципів.
Проаналізуємо детально переваги та недоліки основних типів сенсорів, що
можуть бути інтегровані на мобільні платформи.
1 Оптичні сенсори видимого спектра (RGB-камери)
Найпоширенішим типом сенсорів є цифрові камери, що працюють у
видимому діапазоні електромагнітного випромінювання (довжина хвилі 380–
13
ЧДТУ 252496.016 ПЗ
750 нм).
Принцип дії: Формування зображення базується на реєстрації відбитого
від об'єктів сонячного світла за допомогою матриць ПЗЗ (CCD) або КМОН
(CMOS). CMOS-сенсори є кращими для БПЛА через менше енергоспоживання
та можливість порядкового зчитування (rolling shutter) або глобального затвора
(global shutter).
Переваги: Висока роздільна здатність (4K і вище), що дозволяє виявляти
дрібні об'єкти з великої висоти; низька вартість; наявність величезних масивів
даних для навчання нейромереж.
Недоліки: Критична залежність від умов освітлення (неможливість
роботи вночі), нездатність "бачити" крізь рослинність або шар ґрунту.
Ефективні лише для виявлення об'єктів, що знаходяться на поверхні.
Рис. 1.1 – Демонстрація спектру сигналів
2 Інфрачервоні сенсори (Тепловізори)
Працюють у довгохвильовому інфрачервоному діапазоні (LWIR, 8–14
мкм).
Фізичне обґрунтування. Метод базується на явищі теплової інерції.
Металеві або пластикові корпуси мін мають іншу теплоємність та
теплопровідність, ніж навколишній ґрунт. Протягом добового циклу (нагрівання
14
ЧДТУ 252496.016 ПЗ
вдень і охолодження вночі) виникають періоди, коли температурний контраст
між міною та ґрунтом стає максимальним. Цей ефект дозволяє виявляти навіть
прикопані або замасковані об'єкти.
Обмеження. Висока вартість сенсорів з достатньою роздільною
здатністю, залежність від погодних умов (дощ або туман розсіюють ІЧ-
випромінювання), складність інтерпретації зображень.
3 Мультиспектральні та гіперспектральні камери
Ці системи фіксують зображення не в трьох каналах (R, G, B), а в
десятках або сотнях вузьких спектральних смугах, включаючи ближній
інфрачервоний (NIR) та ультрафіолетовий діапазони.
Застосування. Дозволяють виявляти аномалії рослинності (стрес
рослин), спричинені витоком хімічних речовин з вибухівки, або розпізнавати
"спектральні підписи" (signatures) штучних матеріалів (пластик, метал, фарба),
які для людського ока зливаються з фоном.
4 Магнітометри та георадари (GPR)
Магнітометри реагують на збурення магнітного поля Землі
феромагнітними об'єктами. Основна проблема при використанні на дронах –
електромагнітні завади від власних двигунів БПЛА.
Георадари (GPR) випромінюють радіохвилі в ґрунт і аналізують
відбитий сигнал. Це єдиний надійний метод для пошуку глибоко закопаних
об'єктів (пластикових мін), проте обладнання GPR зазвичай занадто важке для
легких тактичних дронів і вимагає польоту на наднизькій висоті (менше 1 м),
що є складним завданням для автопілота.
Отже враховуючи обмеження вантажопідйомності масових комерційних
дронів (типу DJI Mavic, Autel) та FPV-платформ, найбільш раціональним є
використання оптичного каналу (RGB) у поєднанні з передовими алгоритмами
комп'ютерного зору. Це дозволяє використовувати стандартне обладнання,
перекладаючи основне навантаження з "заліза" на програмне забезпечення та
штучний інтелект.
1.2 Еволюція методів глибокого навчання для задач детекції об'єктів
15
ЧДТУ 252496.016 ПЗ
1.2.1 Класичні підходи проти глибокого навчання
Історія комп'ютерного зору (Computer Vision, CV) поділяється на дві
великі епохи: до 2012 року (класичні методи) та після (ера глибокого навчання).
Класичні методи (Classic CV)
До появи потужних GPU задача детекції вирішувалася шляхом ручного
конструювання ознак (hand-crafted features). Алгоритм роботи виглядав
наступним чином:
1 Виділення ознак. Використовувалися дескриптори типу SIFT (Scale-
Invariant Feature Transform), SURF або HOG (Histogram of Oriented Gradients).
Наприклад, HOG аналізував напрямок градієнта яскравості в локальних
областях зображення, що дозволяло описувати форму об'єкта.
2 Класифікація. Отримані вектори ознак подавалися на вхід класичних
класифікаторів машинного навчання, таких як метод опорних векторів (SVM –
Support Vector Machine) або випадковий ліс (Random Forest).
3 Ковзаюче вікно. Для пошуку об'єкта вікно фіксованого розміру
переміщувалося по всьому зображенню з певним кроком, що вимагало
колосальних обчислювальних ресурсів.
Відомим прикладом є метод Віоли-Джонса (2001) для детекції облич,
який використовував каскади Хаара. Хоча ці методи були швидкими для
простих задач, вони виявилися безсилими перед складними сценами, зміною
освітлення та деформацією об'єктів, що є типовим для задачі пошуку ВНП у
польових умовах.
Ера глибокого навчання (Deep Learning).
Революція відбулася з появою згорткових нейронних мереж (Convolutional
Neural Networks – CNN). На відміну від класичних методів, CNN автоматично
формують ієрархію ознак у процесі навчання.
Нижні шари мережі вчаться реагувати на прості примітиви (лінії, кути,
кольорові плями).
Середні шари комбінують їх у складніші форми (текстури, частини
предметів).
16
ЧДТУ 252496.016 ПЗ
Верхні шари розпізнають цілісні об'єкти.
Математично операція згортки для вхідного зображення I та ядра K
записується як:
Це дозволило досягти безпрецедентної стійкості до змін масштабу,
повороту та освітлення.
1.2.2 Класифікація архітектур детекції: Two-Stage vs One-Stage
Сучасні детектори на базі CNN поділяються на дві основні парадигми.
Двоетапні детектори (Two-Stage Detectors).
Представники: R-CNN, Fast R-CNN, Faster R-CNN, Mask R-CNN.
Ці алгоритми розбивають задачу на два послідовні кроки:
1 Region Proposal (Генерація гіпотез).
Мережа спочатку знаходить області зображення, де ймовірно знаходиться
об'єкт (Region of Interest – RoI). У Faster R-CNN для цього використовується
спеціальна підмережа RPN (Region Proposal Network).
2 Classification & Refinement.
Виділені області масштабуються до фіксованого розміру і подаються на
класифікатор для визначення типу об'єкта та уточнення координат рамки.
Переваги. Дуже висока точність локалізації.
Недоліки. Низька швидкість роботи (зазвичай 5–15 FPS), що робить їх
непридатними для використання на дронах у реальному часі.
Одноетапні детектори (One-Stage Detectors).
Представники: SSD (Single Shot MultiBox Detector), RetinaNet, сімейство
YOLO (You Only Look Once). Ці архітектури розглядають детекцію як єдину
задачу регресії. Зображення подається на вхід мережі один раз, і на виході
миттєво отримуються тензори з координатами рамок та ймовірностями класів.
Принцип роботи. Зображення ділиться на сітку (наприклад, $S \times S$).
Кожна комірка сітки відповідає за детекцію об'єкта, центр якого потрапляє в цю
комірку.
Переваги. Висока швидкість (до 140+ FPS на сучасних GPU), можливість
17
ЧДТУ 252496.016 ПЗ
роботи на мобільних пристроях.
Недоліки. Історично мали меншу точність при детекції малих об'єктів
порівняно з двоетапними методами, але в останніх версіях (YOLOv8/v11) цей
розрив майже нівельовано.
Рис 1.2 – Порівняння One-Stage та Two-Stage детекторів
1.2.3 Аналіз еволюції сімейства YOLO
Архітектура YOLO пройшла довгий шлях еволюції, кожна версія якої
вносила критичні покращення:
− YOLOv1 (2016). Революційна ідея "one-shot" детекції. Недолік – погано
виявляла скупчення об'єктів.
− YOLOv3. Впровадження FPN (Feature Pyramid Network), що дозволило
18
ЧДТУ 252496.016 ПЗ
робити детекцію на трьох різних масштабах. Це критично покращило
розпізнавання дрібних об'єктів.
− YOLOv4/v5. Оптимізація функцій активації (Mish, SiLU) та введення
технік "Bag of Freebies" (аугментації Mosaic, MixUp) та "Bag of Specials"
(архітектурні зміни CSPNet).
− YOLOv8 (2023). Перехід на Anchor-Free підхід. Відмова від жорстко
заданих якорів (anchors) зробила модель більш гнучкою та спростила
процес навчання.
− YOLOv11 (2024). Подальша оптимізація кількості параметрів та
покращення механізму уваги (Attention Mechanism), що забезпечує кращу
роботу в складних умовах.
Саме Anchor-Free архітектура сучасних YOLO є оптимальним вибором
для детекції мін, які можуть мати нестандартну форму та орієнтацію в просторі.
1.3 Проблематика впровадження ML-моделей на Edge-пристроях
1.3.1 Обмеження обчислювальних ресурсів та енергоспоживання
Впровадження нейромереж на борту БПЛА стикається з жорсткими
апаратними обмеженнями, що визначаються терміном Edge Computing
("обчислення на краю"). На відміну від хмарних серверів з потужними
відеокартами (наприклад, NVIDIA A100), бортовий комп'ютер дрона має
обмежений бюджет енергії (зазвичай 5–15 Вт) та ваги.
Основними платформами для таких задач є одноплатні комп'ютери (SBC):
1 Raspberry Pi 4/5. Дешеві та доступні, але мають лише CPU. Інференс
YOLO на CPU дає вкрай низьку швидкість (1–3 FPS), що неприйнятно для
польоту.
2 NVIDIA Jetson (Nano, TX2, Xavier, Orin). Спеціалізовані рішення, що
мають вбудовані ядра CUDA та тензорні ядра (Tensor Cores). Це дозволяє
виконувати паралельні обчислення матриць, необхідні для нейромереж,
досягаючи швидкості 30–60 FPS при енергоспоживанні 10 Вт.
Проблема затримки (Latency)
19
ЧДТУ 252496.016 ПЗ
Для дрона, що рухається зі швидкістю 10–15 м/с, критичною є затримка
обробки. Якщо система обробляє кадр 200 мс (5 FPS), дрон пролетить 2-3 метри
між моментом зйомки і моментом прийняття рішення. Це може призвести до
пропуску міни або занадто пізньої реакції. Тому необхідна оптимізація.
Методи оптимізації:
− Квантування (Quantization). Переведення ваг моделі з формату
числа з плаваючою комою FP32 (32 біти) у цілочисельний формат INT8 (8 біт).
Це зменшує розмір моделі в 4 рази та прискорює обчислення, втрачаючи менше
1% точності.
− Прунінг (Pruning). Видалення "зайвих" нейронів та зв'язків, які
мають малі вагові коефіцієнти і слабо впливають на результат.
− Використання TensorRT. Спеціалізований оптимізатор від NVIDIA,
який "компілює" нейромережу під конкретну архітектуру GPU, об'єднуючи
шари та оптимізуючи використання пам'яті.
Таким чином, розробка системи виявлення для БПЛА – це пошук балансу
між точністю моделі (mAP), швидкістю її роботи (FPS) та енергоефективністю
платформи.
1.4 Аналіз проблеми детекції малих об'єктів (Small Object Detection)
Окрім апаратних викликів, існує специфічна алгоритмічна проблема,
притаманна саме задачам аеророзвідки – проблема масштабу об'єктів.
1.4.1 Визначення та статистика проблеми
Згідно з загальноприйнятою метрикою MS COCO, об'єкти поділяються на
три категорії за площею:
− Small (Малі): площа < пікселів.
− Medium (Середні): площа від до пікселів.
− Large (Великі): площа > пікселів.
При зйомці з висоти 20-30 метрів на камеру з широким кутом огляду, міна
типу ПФМ-1 може займати на зображенні всього 10-15 пікселів. Це відносить її
до категорії "екстремально малих" об'єктів. Статистика показує, що точність
20
ЧДТУ 252496.016 ПЗ
сучасних детекторів (SOTA) на малих об'єктах зазвичай у 2-3 рази нижча, ніж
на великих.
1.4.2 Феномен зникнення ознак (Feature Vanishing)
Сучасні згорткові мережі побудовані за пірамідальним принципом.
Проходячи через шари мережі, просторова роздільна здатність карт ознак
(Feature Maps) зменшується через операції пулінгу (Pooling) або згортки з
кроком (Stride).
Стандартний максимальний крок у мережах YOLO становить 32. Це
означає, що вхідне зображення зменшується у 32 рази.
Математична колізія. Якщо об'єкт на вході має розмір 16 пікселів, то на
фінальній карті ознак його проекція становитиме $16 / 32 = 0.5$ пікселя.
Наслідок. Інформація про об'єкт фактично "розчиняється" або зливається
з фоном. Об'єкт зникає з поля зору мережі ще до етапу класифікації.
1.4.3 Недоліки стандартного методу Resizing
Стандартний пайплайн інференсу передбачає зміну розміру вхідного
зображення до фіксованого квадрату (наприклад, 640x640 пікселів) для
забезпечення пакетної обробки.
При роботі з камерами 4K або Full HD (1920x1080), такий "Downscaling"
призводить до незворотної втрати високочастотних деталей. Для танка чи
будівлі це не критично, оскільки їх силует зберігається. Але для малогабаритної
міни, яка розрізняється лише за текстурою поверхні, таке стиснення є
фатальним.
21
ЧДТУ 252496.016 ПЗ
Висновки до розділу
Проведений у даному розділі комплексний аналіз дозволяє зробити
наступні узагальнюючі висновки, що формують технічне завдання на розробку
системи:
1 Вибір сенсора: Оптичні камери є оптимальним вибором для масових
систем розмінування завдяки доступності та високій інформативності, проте
вони потребують інтелектуальних алгоритмів обробки для компенсації факторів
середовища.
2 Архітектура: Одностадійний детектор YOLOv11 є найбільш
перспективною базовою архітектурою, оскільки пропонує найкращий баланс
між швидкістю та точністю, а також має Anchor-Free природу, що спрощує
детекцію нестандартних об'єктів.
3 Критична проблема: Головним викликом є не стільки класифікація,
скільки саме виявлення (Recall) малих об'єктів, які втрачаються при
стандартних методах попередньої обробки зображень.
4 Напрямок рішення: Для вирішення виявлених проблем необхідно
розробити спеціалізований програмний конвеєр, який відмовляється від
глобального стиснення зображень на користь методів нарізки (Tiling) та
використовує методи ансамблювання (TTA) для підвищення надійності, при
цьому враховуючи обмежені ресурси цільових апаратних платформ.
Ці висновки є фундаментом для теоретичних та практичних досліджень у
наступних розділах.
22
ЧДТУ 252496.016 ПЗ
РОЗДІЛ 2 ТЕОРЕТИЧНІ ТА ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ
У даному розділі розглядаються теоретичні аспекти функціонування
згорткових нейронних мереж у режимі інференсу (прямого поширення
сигналу). Проводиться формалізація математичних операцій, що виконуються
на етапах попередньої обробки, проходження сигналу через шари архітектури
YOLOv11, а також алгоритмічні засади постобробки результатів (декодування
тензорів, фільтрація NMS) та методів просторової адаптації зображень
(тайлінг).
2.1 Математична модель прямого поширення сигналу (Forward Pass)
Процес інференсу глибокої нейронної мережі з математичної точки зору є
послідовним перетворенням вхідного тензора X через композицію нелінійних
функцій шарів мережі fI. Для вхідного зображення вихід Y
визначається як:
, де кожен шар fI. виконує специфічну матричну
або поелементну операцію. Основне обчислювальне навантаження під час
інференсу припадає на згорткові шари.
2.1.1 Дискретна згортка та обчислювальна складність
На етапі інференсу ваги ядра W є фіксованими константами. Значення
вихідного елемента карти ознак Ox,y на каналі k обчислюється як сума добутків
ваг на відповідні пікселі вхідного регіону:
де:
Cin– кількість вхідних каналів;
Kh, Kw – розмір ядра згортки;
k
b – зміщення (bias) для k-го фільтра.
Теоретична оцінка обчислювальної складності (FLOPs).
Для оцінки придатності моделі до запуску на Edge-пристроях
23
ЧДТУ 252496.016 ПЗ
використовується метрика FLOPs (Floating Point Operations). Для одного
згорткового шару кількість операцій складає:
Аналіз цієї формули показує, що для оптимізації інференсу критично
важливим є зменшення розмірності карт ознак або кількості
каналів, що реалізується в YOLOv11 через механізми Strided Convolution.
2.1.2 Функції активації в контексті поширення сигналу
Після лінійної операції згортки сигнал проходить через нелінійну
функцію активації. У режимі інференсу важливою характеристикою функції є
складність її обчислення процесором.
У YOLOv11 використовується SiLU (Sigmoid Linear Unit):
З точки зору обчислень на CPU, ця функція є дорожчою за класичну ReLU
( ), оскільки вимагає обчислення експоненти. Проте, вона забезпечує
краще збереження інформаційного потоку в глибоких шарах, запобігаючи
затуханню слабких сигналів, що є критичним для детекції дрібних об'єктів.
2.2 Теоретичні засади структурного аналізу складних систем обробки
даних
Проєктування сучасних програмно-апаратних комплексів, зокрема систем
комп'ютерного зору для автономних платформ, є багатогранним завданням, яке
виходить далеко за межі написання програмного коду. Складність внутрішніх
взаємозв'язків між підсистемами захоплення відео, модулями попередньої
обробки даних та нейромережевими алгоритмами вимагає застосування
суворих інженерних підходів до архітектури системи. Для забезпечення
надійності, відмовостійкості та масштабованості розроблюваного рішення
доцільно використовувати методологію структурного аналізу та проєктування
(SADT – Structured Analysis and Design Technique).
Структурний аналіз являє собою систематизований набір методів та
24
ЧДТУ 252496.016 ПЗ
графічних нотацій, що дозволяють перетворити нечіткі, вербальні описи
предметної області у формалізовані специфікації. В основі цього підходу
лежить принцип декомпозиції – розбиття складної системи на менші, керовані
компоненти (підсистеми), які легше аналізувати, розробляти та тестувати
окремо. Такий підхід ("зверху-вниз") дозволяє розробнику абстрагуватися від
деталей реалізації на початкових етапах і зосередитися на логічній цілісності
системи.
Особливої актуальності структурний аналіз набуває при роботі з
системами реального часу (Real-time systems), до яких належать БПЛА та інші
автономні платформи. У таких системах критично важливим є не лише
правильність обчислень, а й час, витрачений на обробку даних та передачу
керуючих сигналів. Використання формальних моделей дозволяє виявити
потенційні архітектурні помилки ще до початку етапу імплементації. У рамках
даної кваліфікаційної роботи використовуються два фундаментальні стандарти
структурного аналізу: методологія функціонального моделювання IDEF0 та
методологія моделювання потоків даних DFD.
2.2.1 Методологія функціонального моделювання IDEF0
Стандарт IDEF0 (Integration Definition for Function Modeling) бере свій
початок від методології SADT, розробленої Дугласом Россом, і згодом був
стандартизований у рамках програми ICAM Повітряних сил США. Цей
стандарт призначений для опису бізнес-процесів та функціональної структури
систем будь-якої складності.
Ключовою особливістю IDEF0 є розгляд системи не як набору статичних
об'єктів, а як сукупності взаємопов'язаних функцій (дій). Графічна нотація
базується на використанні функціональних блоків (прямокутників) та дуг
(стрілок), що їх з'єднують. Важливою характеристикою є чітка семантика
розташування стрілок відносно сторін функціонального блоку (концепція
ICOM):
1 Вхідні дані (Input – ліва сторона): Матеріали або інформація, що
перетворюються функцією. У контексті системи детекції це
25
ЧДТУ 252496.016 ПЗ
насамперед "сирий" відеопотік з камери, телеметричні дані про висоту
та швидкість польоту, а також метадані сенсорів. Ці дані є пасивними
й підлягають обробці.
2 Керування (Control – верхня сторона): Дані, що керують
виконанням функції, але не перетворюються нею. Це можуть бути
конфігураційні файли з вагами нейромережі, порогові значення
впевненості (confidence threshold), команди оператора або обмеження
польотного завдання. Керуючі сигнали визначають, як і коли функція
повинна виконуватися.
3 Вихідні дані (Output – права сторона): Результат виконання функції.
Це може бути масив координат виявлених об'єктів (bounding boxes),
класифіковані зображення, сигнали тривоги або логи роботи системи.
Вихід одного блоку часто стає входом або керуванням для іншого.
4 Механізми (Mechanism – нижня сторона): Ресурси, що виконують
функцію. Сюди відносяться як апаратні засоби (бортовий комп'ютер
типу NVIDIA Jetson, оптичні сенсори), так і програмні інструменти
(бібліотеки OpenCV, фреймворк YOLO, операційна система Ubuntu).
Процес моделювання починається з побудови контекстної діаграми
(рівень А-0), яка представляє всю систему як єдиний "чорний ящик", фіксуючи
її межі та взаємодію із зовнішнім середовищем. Надалі відбувається ієрархічна
декомпозиція, де кожен блок розбивається на більш детальні діаграми (діаграми
нащадків). Для системи виявлення об'єктів така деталізація дозволяє
відокремити процес захоплення кадру від процесу інференсу та процесу
прийняття рішень, чітко визначивши відповідальність кожного модуля.
2.2.2 Методологія моделювання потоків даних (DFD)
Якщо IDEF0 відповідає на запитання "Що робить система?",
фокусуючись на підпорядкованості функцій, то діаграми потоків даних (DFD –
Data Flow Diagrams) відповідають на запитання "Як рухається інформація?".
Для програмних систем обробки відеоданих цей аспект є критичним,
26
ЧДТУ 252496.016 ПЗ
оскільки ефективність роботи залежить від швидкості передачі великих масивів
даних (тензорів зображень) між оперативною пам'яттю, процесором (CPU) та
графічним прискорювачем (GPU).
Методологія DFD дозволяє абстрагуватися від керуючих сигналів і
зосередитися виключно на траєкторії даних. Класична нотація DFD включає
чотири базові елементи:
− Зовнішні сутності (External Entities): Це джерела даних або їх
кінцеві споживачі, що знаходяться поза межами модельованої системи. У
нашому випадку зовнішніми сутностями виступають фізичне середовище
(сцена, що знімається), апаратний модуль камери та оператор комплексу, який
отримує результати аналізу.
− Процеси (Processes): Це дії, що трансформують вхідні потоки даних у
вихідні. Процеси в DFD можуть варіюватися від простих операцій (зміна
розміру зображення, нормалізація кольору) до складних алгоритмічних
процедур (прогонка зображення через згорткові шари нейромережі,
застосування алгоритму Non-Maximum Suppression).
− Сховища даних (Data Stores): Це місця, де дані зберігаються в стані
спокою. Це можуть бути як фізичні файли на диску (наприклад, файл
конфігурації .pt з вагами моделі, відеоархів), так і буфери в оперативній пам'яті
(черга кадрів для обробки). Аналіз сховищ дозволяє оцінити вимоги до пам'яті
пристрою.
− Потоки даних (Data Flows): Маршрути, якими пакети інформації
переміщуються між процесами, сутностями та сховищами. Аналіз потоків
допомагає виявити "вузькі місця" (bottlenecks), де можливе накопичення черги
даних, що призводить до затримок (latency) у роботі системи реального часу.
Важливим аспектом DFD є можливість побудови як логічної моделі (що
система робить концептуально), так і фізичної моделі (як це реалізовано
програмно). У даній роботі акцент робиться на логічній структурі потоків
відеоданих, що дозволяє спроєктувати оптимальний конвеєр (pipeline) обробки.
2.2.3 Синтез структурних моделей та перехід до проєктування
27
ЧДТУ 252496.016 ПЗ
Комплексне використання методологій IDEF0 та DFD забезпечує
різнобічний погляд на проєктовану систему. IDEF0 створює ієрархічний каркас
функціональності, гарантуючи, що всі вимоги до системи враховані та жодна
функція не залишилася без механізму реалізації. Своєю чергою, DFD наповнює
цей каркас розумінням динаміки даних, дозволяючи оптимізувати інформаційні
маршрути.
Такий комбінований підхід створює надійну базу для наступних етапів
розробки: вибору конкретних структур даних, проєктування інтерфейсів та
написання програмного коду. Побудовані діаграми слугують не лише
документацією, а й планом для реалізації архітектури програмного
забезпечення, мінімізуючи ризики виникнення логічних помилок на етапі
інтеграції модулів OpenCV та нейромережі YOLO.
2.3 Структурний аналіз архітектури YOLOv11 з точки зору інференсу
Архітектура YOLOv11 розроблена з урахуванням мінімізації затримок
(latency) при збереженні точності. Розглянемо функціонування її блоків саме в
процесі виконання.
2.3.1 Ефективність блоків C3k2 та CSP
Основний будівельний блок C3k2 базується на концепції CSP (Cross Stage
Partial). Під час інференсу вхідний тензор $X$ розділяється на два потоки:
1 Магістральний потік: проходить через серію згорток 1*1 та 3*3
(Bottleneck).
2 Шунтуючий потік: передається напряму через просту згортку.
Фінальна операція конкатенації об'єднує ці потоки. Така структура
дозволяє мережі мати "швидкий шлях" для проходження градієнтів (при
навчанні) та ознак (при інференсі), зменшуючи кількість необхідних
математичних операцій порівняно з повними згортковими блоками (Dense
Blocks).
2.3.2 Пірамідальне формування ознак (SPPF та PANet)
28
ЧДТУ 252496.016 ПЗ
У задачах аеророзвідки об'єкти можуть мати різний масштаб. Для обробки
цього фактору мережа використовує багаторівневу структуру.
− SPPF (Spatial Pyramid Pooling Fast): Виконує послідовний Max
Pooling з ядром 5*5. Під час інференсу це дозволяє отримати глобальний
контекст зображення з мінімальними витратами пам'яті, оскільки проміжні
результати пулінгу перевикористовуються.
− Feature Fusion (PANet): На етапі Neck відбувається злиття тензорів
різної роздільної здатності (Upsampling + Concatenation). Це найбільш
ресурсоємна частина після Backbone, оскільки оперує великими обсягами
пам'яті для зберігання карт ознак високої роздільної здатності.
2.4 Алгоритмічні основи постобробки результатів (Post-Processing)
Вихід нейронної мережі YOLO – це не готова картинка з рамками, а
"сирий" тензор, який потребує математичного декодування. Цей етап
виконується на CPU і часто стає "вузьким місцем" пайплайну.
2.4.1 Декодування Anchor-Free передбачень
Вихідний тензор має розмірність N*(4+Cclasses), де N – кількість
потенційних детекцій (кандидатів).
YOLOv11 використовує Anchor-Free підхід, де координати
передбачаються відносно центру комірки сітки (Cx,Cy).
Мережа видає чотири значення розподілу відстаней: $ltrb$ (left, top, right,
bottom). Перетворення у реальні координати зображення (xmin, ymin, xmax, ymax)
відбувається за формулами:
де
S – крок сітки (stride) даного рівня піраміди ознак.
2.4.2 Теоретичні засади фільтрації (Non-Maximum Suppression)
29
ЧДТУ 252496.016 ПЗ
"Сирий" вихід мережі містить тисячі дубльованих рамок навколо одного
об'єкта. Для їх фільтрації застосовується алгоритм NMS (Non-Maximum
Suppression).
Це "жадібний" алгоритм, який базується на метриці IoU (Intersection over
Union):
Алгоритм інференсу NMS:
1 Відсортувати всі рамки за спаданням впевненості (Confidence Score).
2 Обрати рамку A з найвищою оцінкою.
3 Видалити всі інші рамки $B$, для яких (де – поріг
перекриття, зазвичай 0.45-0.5).
4 Повторювати кроки 2-3, доки список кандидатів не стане порожнім.
2
Обчислювальна складність NMS квадратична O(N ) у найгіршому
випадку, тому ефективна реалізація цього етапу є критичною для швидкодії
системи.
2.5 Теоретичне обґрунтування методів просторової обробки
зображень
Для вирішення проблеми детекції малих об'єктів, яка є специфічною для
аеророзвідки, застосовується алгоритмічна надбудова над нейромережею –
тайлінг.
2.5.1 Формалізація методу Tiling (Slicing Aided Inference)
Метод базується на гіпотезі, що збереження високої частоти просторових
даних (деталізації) є важливішим за збереження глобального контексту сцени.
Нехай вхідне зображення I має розміри W*H. Ми визначаємо вікно
сканування (тайл) розміром w*h та кроки зміщення Sx,Sy.
Множина тайлів {Ti,j} формується шляхом вирізання областей:
Ti,j = I[yi : yi + h, xi : xj + w] де xj = j * sx, yi = i * sy .
Важливим теоретичним аспектом є Overlap Ratio (коефіцієнт перекриття).
Перекриття необхідне для уникнення "крайового ефекту" (Edge Effect), коли
30
ЧДТУ 252496.016 ПЗ
об'єкт розрізається навпіл межею тайлів і не детектується жодним з проходів.
2.5.2 Трансформація координат та злиття детекцій
Після інференсу кожного тайла локальні координати детекцій Blocal
повинні бути спроектовані назад у глобальний простір Bglobal.
Для k-ї детекції на тайлі (i, j):
Після злиття виникає проблема надлишкових детекцій у зонах
перекриття. Для її вирішення застосовується глобальний NMS, який розглядає
весь простір зображення як єдине ціле.
2.6 Математична модель Test-Time Augmentation (TTA)
TTA є методом підвищення робастності (стійкості) інференсу без зміни
ваг моделі.
Математично це можна описати як апроксимацію інтеграла по простору
можливих збурень вхідного сигналу.
Нехай f(x) – функція інференсу мережі. Ми вводимо множину
трансформацій , де I – тотожне перетворення.
Результат інференсу з TTA є агрегацією результатів:
, де $T^{-1}$ – обернена трансформація
координат (наприклад, якщо ми віддзеркалили зображення перед входом, ми
повинні віддзеркалити координати рамок на виході).
Функція агрегації Agg зазвичай є зваженим усередненням впевненості та
координат, що дозволяє зменшити дисперсію передбачень та нівелювати
випадкові помилки мережі на складних фонах.
31
ЧДТУ 252496.016 ПЗ
Висновки до розділу
У даному розділі розглянуто теоретичні засади побудови системи
комп'ютерного зору в аспекті інференсу.
1 Проаналізовано математичну модель прямого поширення сигналу та
оцінено обчислювальну складність згорткових операцій, що є основою для
розуміння продуктивності на CPU.
2 Детально розглянуто архітектуру YOLOv11 та її механізми (CSP,
SPPF) з точки зору ефективності виконання.
3 Формалізовано алгоритми постобробки даних (декодування Anchor-
Free, NMS), які є невід'ємною частиною пайплайну детекції.
4 Наведено теоретичне обґрунтування методів просторової адаптації
(Tiling) та підвищення стійкості (TTA), які дозволяють компенсувати втрату
інформації при обробці зображень високої роздільної здатності.
32
ЧДТУ 252496.016 ПЗ
РОЗДІЛ 3 ВПРОВАДЖЕННЯ РЕЗУЛЬТАТІВ ДОСЛІДЖЕНЬ У
ПРАКТИКУ ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНИХ СИСТЕМ
У даному розділі проводиться всебічний аналіз етапів проектування,
архітектурного моделювання та програмної імплементації програмно-
апаратного комплексу "HELIOS Professional Mine Detector". Детально
розглядається декомпозиція системи на рівні модулів та класів, обґрунтовується
вибір технологічного стеку, описуються алгоритми керування потоками
виконання та ресурсами пам'яті. Особливу увагу приділено візуальному
моделюванню системи за допомогою мови UML (Unified Modeling Language),
що включає діаграми прецедентів, класів, послідовності, діяльності,
компонентів та розгортання.
3.1 Моделювання предметної області
При проектуванні системи, призначеної для використання в критично
важливих умовах (гуманітарне розмінування), було застосовано підхід,
орієнтований на надійність (Reliability), модульність (Modularity) та швидкодію
(Performance).
3.1.1 Предметна область моделювання. Модель предметної області.
Словник предметної області
Предметна область моделювання охоплює процеси дистанційної
візуальної розвідки територій на наявність ВНП. Специфіка цієї області полягає
в необхідності обробки відеоданих високої роздільної здатності в умовах
обмеженого часу та обчислювальних ресурсів.
Модель предметної області. Архітектура додатку побудована на
модифікованому патерні Model-View-Controller (MVC), адаптованому для
настільних додатків на мові Python. Такий поділ дозволяє незалежно розвивати
ядро детекції та інтерфейс користувача.
1 Model (Модель – Backend): Реалізована у класі HeliosMineDetector
33
ЧДТУ 252496.016 ПЗ
(файл helios_detector.py).
− Відповідальність. Це "мозок" системи. Він відповідає за
ініціалізацію середовища виконання, завантаження ваг
нейромережі, попередню обробку зображень (preprocessing),
виконання інференсу, застосування евристик покращення (TTA,
Tiling) та фінальну агрегацію результатів (WBF/NMS).
− Автономність. Модель спроектована так, щоб працювати незалежно
від графічного інтерфейсу (наприклад, у режимі CLI на сервері або
у складі автоматизованих скриптів).
2 View (Представлення – Frontend): Реалізована у класі HeliosGUI
(файл helios_gui.py).
− Відповідальність. Це "обличчя" системи. Забезпечує візуалізацію
відеопотоку, відображення елементів керування (кнопки, слайдери,
файлові діалоги) та таблиць результатів. Реалізовано на базі
бібліотеки tkinter з використанням віджетів ttk для сучасного
вигляду.
3 Controller (Контролер – Logic): Функції контролера виконує логіка
зв'язування подій (Event Binding) у HeliosGUI та вбудований менеджер потоків
(threading). Контролер перехоплює дії користувача, валідує вхідні дані та
оркеструє виклики методів моделі у фонових потоках, щоб уникнути
блокування інтерфейсу.
Словник предметної області фіксує термінологію, що є фундаментом
проекту. Уніфікація термінів запобігає логічним помилкам при проектуванні
бази даних та інтерфейсів.
Таблиця 3.1
Словник предметної області
Термін Опис та значення для системи
Батч (Batch) Пакет зображень, що подаються на вхід мережі
одночасно для прискорення обробки.
34
ЧДТУ 252496.016 ПЗ
Продовження таблиці 3.1
Впевненість Числове значення [0..1], що відображає ймовірність того,
(Confidence) що знайдений об’єкт належить до заданого класу.
Поріг детекції Мінімальний рівень впевненості, нижче якого
(Conf Thresh) передбачення ігноруються для зменшення кількості
хибних тривог.
Тайлінг (Tiling) Процес розбиття великого кадру на менші фрагменти для
збереження піксельної деталізації малих об’єктів.
Перекриття Частина тайла, що дублює сусідній тайл, необхідна для
(Overlap) детекції об’єктів на межах розрізу.
Ансамблювання Об’єднання результатів роботи кількох моделей або
(Ensembling) кількох проходів однієї моделі для підвищення точності.
Квантування Техніка стиснення моделі шляхом переходу від чисел з
(Quantization) плаваючою комою (FP32) до цілих чисел (INT8) для
швидкості.
Локалізація Задача визначення точних координат обмежувальної
(Localization) рамки об’єкта на зображенні.
mAP@50 Середня точність при порозі IoU рівному 0.5; основна
метрика якості системи.
3.1.2 Елементи моделювання предметної області
Вибір технологічного стеку базувався на необхідності забезпечення
кросплатформеності та високої продуктивності інференсу.
− Мова програмування: Python 3.9+. Обрана через домінування у
сфері ML/AI, наявність широкої екосистеми бібліотек та простоту інтеграції
C++ модулів (через OpenCV/PyTorch).
− GUI Фреймворк: Tkinter. Обрано замість Qt або Electron через:
− Легковаговість: Мінімальне споживання оперативної пам'яті, що
критично для польових ноутбуків з 4-8 ГБ RAM.
35
ЧДТУ 252496.016 ПЗ
− Нативність: Входить у стандартну бібліотеку Python, що спрощує
розгортання (не потребує складних інсталяторів).
− Computer Vision: OpenCV (cv2). Використовується для
високоефективних матричних операцій над зображеннями (нарізка тайлів,
геометричні трансформації) на рівні C++, що забезпечує мінімальні затримки.
− AI Core: Ultralytics YOLO + PyTorch. Забезпечує State-of-the-Art
точність детекції, підтримку динамічних архітектур (YOLOv8/v11) та прозору
роботу з апаратним прискоренням (CUDA/MPS).
3.1.3 Робоча область моделювання
Формулювання робочої області моделювання (Modeling Working Area) є
центральним етапом структурної ідентифікації. Відповідно до інженерних
стандартів, робоча область моделювання – це сукупність методів, правил,
процедур та інструментальних засобів, призначених для побудови
функціональної та структурної моделі об'єкта в межах конкретної предметної
області.
У контексті системи розпізнавання малогабаритних об'єктів, робоча
область моделювання системи HELIOS визначається наступними параметрами:
− концептуальний простір: Перехід від фізичних параметрів міни
ПФМ-1 (розмір 119х64 мм, поліетиленовий корпус) до їх цифрових
дескрипторів у тензорному представленні.
− методологічні межі: Використання діаграм прецедентів для фіксації
вимог оператора, діаграм класів для проектування логічної структури та діаграм
діяльності для опису алгоритмів адаптивного інференсу (Tiling+TTA).
− технологічне середовище: Робоча область обмежена використанням
мови Python 3.12, екосистеми PyTorch/Ultralytics та бібліотеки OpenCV, що
визначає способи маніпуляції даними та формати передачі повідомлень між
модулями.
− специфікація оточення: Врахування факторів «Edge Computing», де
робоча область моделювання повинна мінімізувати затримки (latency) та
споживання пам'яті, що досягається через багатопотоковість та асинхронність
36
ЧДТУ 252496.016 ПЗ
взаємодії GUI з ядром обробки.
Таким чином, робоча область моделювання в даній роботі – це не просто
набір інструментів, а структуроване середовище, де інтегруються математичні
моделі нейронних мереж із програмними інтерфейсами керування,
забезпечуючи цілісність процесу від захоплення кадру до генерації звіту про
мінну небезпеку.
3.2 Формування та аналіз вимог
3.2.1 Формування вимог до програмного забезпечення. Первинні і
детальні вимоги. Вимоги замовника і розробника. Функціональні та
нефункціональні вимоги.
Для побудови чогось, передусім, необхідно зрозуміти, чим це повинно
бути і що робить система. Тому процес розуміння та його документування
називається аналізом вимог.
Вимога – це умова чи можливість, якій повинна відповідати система.
Основна задача етапу визначення вимог – знайти, обговорити і зафіксувати, що
дійсно вимагається від системи у зрозумілій формі як клієнтам, так і членам
команди розробників. Результатом аналізу вимог є документ, який називають
специфікацією вимог, або специфікацією вимог до програмного забезпечення.
Для моделювання і опису усіх процесів, що протікають під час розробки
додатку, застосовують уніфіковану мову моделювання (UML). Усі діаграми
можна умовно розділити на поведінкові і структурні.
Поведінкові діаграми відображають процеси, що протікають у
модельованому середовищі. Структурні діаграми відображають елементи, з
яких складається система. При цьому одні й ті ж типи діаграм можуть
використовуватися як для моделювання бізнес-процесів, так і для
безпосереднього проектування архітектури.
Формування вимог до програмного забезпечення
Процес формування вимог (Requirements Engineering) у сучасній
інженерії програмного забезпечення охоплює декілька фундаментальних етапів:
37
ЧДТУ 252496.016 ПЗ
виявлення (elicitation), аналіз (analysis), специфікацію (specification) та
валідацію (validation). Кожен із цих етапів має на меті перетворення нечітких
побажань замовника у строгий технічний документ – Специфікацію вимог до
програмного забезпечення (SRS). У контексті розробки систем розпізнавання
малих об’єктів, цей процес починається з аналізу зацікавлених сторін, до яких
відносяться оператори БПЛА, фахівці з протимінної діяльності, розробники
алгоритмів штучного інтелекту та кінцеві користувачі, що працюють у польових
умовах.
Етапи та методології формування вимог
Збір та аналіз вимог є першим кроком SDLC (Software Development Life
Cycle). На цьому етапі бізнес-аналітики та керівники проєктів організовують
зустрічі із замовниками для визначення мети продукту та портрета кінцевого
користувача. Для системи детекції малогабаритних об’єктів асиметричної
форми ключовим фактором є ідентифікація «проблемного простору» (problem
space), де наразі не існує ефективного автоматизованого рішення для виявлення
мін типу ПФМ-1 на фоні складного ландшафту. Процес формування вимог
згідно з міжнародними стандартами представлений у таблиці нижче.
Таблиця 3.2.
Етап процесу
Етап процесу Основні дії та методи Результати етапу
Інтерв'ювання
замовників, опитування Перелік сирих потреб,
Виявлення (Elicitation) користувачів, аналіз сценаріїв використання
нормативної бази (ДСТУ та бізнес-цілей
8820:2018)
38
ЧДТУ 252496.016 ПЗ
Продовження таблиці 3.2
Класифікація вимог,
Узгоджений набір вимог,
вирішення конфліктів
пріоритезація за
Аналіз (Analysis) між точністю та
методами MoSCoW або
швидкістю, побудова
Kano
дерева проблем
Написання документа
SRS за стандартом ISO Документ SRS, готовий
Специфікація
29148, формалізація до передачі розробникам
(Specification)
функціональних та (Dev-ready)
нефункціональних вимог
Рецензування (Reviews),
Затверджена
прототипування,
специфікація, що
Валідація (Validation) перевірка на
відображає реальні
відповідність критеріям
потреби замовника
SMART
Важливим аспектом формування вимог є дотримання принципів SMART.
Кожна вимога повинна бути конкретною (Specific), вимірюваною (Measurable),
досяжною (Achievable), релевантною для бізнесу (Relevant) та обмеженою в
часі (Time-bound). Наприклад, вимога «система повинна працювати швидко» є
неприпустимою через свою двозначність; замість цього розробник має
зафіксувати детальну метрику: «час інференсу одного кадру роздільною
здатністю 1920x1080 пікселів не повинен перевищувати 500 мс на цільовому
CPU».
Стандарти та нормативна база
У вітчизняній та міжнародній практиці інженерії ПЗ ключовим
стандартом є ДСТУ ISO/IEC/IEEE 29148:2015 «Розроблення систем і
програмного забезпечення. Процеси життєвого циклу. Розроблення вимог». Цей
стандарт прийшов на зміну відомому IEEE 830-1998 і пропонує ширший підхід,
39
ЧДТУ 252496.016 ПЗ
що охоплює не лише специфікацію, а й процеси управління вимогами протягом
усього життєвого циклу. Використання таких стандартів забезпечує
простежуваність (traceability) – можливість відстежити кожну вимогу від її
виникнення у бізнес-цілях до конкретного модуля коду та тест-кейсу.
Для спеціалізованого ПЗ у сфері безпеки та розмінування, процес
формування вимог також повинен враховувати національні стандарти, такі як
ДСТУ 34.601–92, що визначає стадії створення автоматизованих систем. У
розрізі проєкту «HELIOS», це означає інтеграцію технічних вимог до точності
детекції з вимогами до захисту інформації та відмовостійкості в умовах
відсутності GPS-сигналу.
Первинні і детальні вимоги
У процесі ідентифікації інформаційних систем вимоги структуруються за
рівнями деталізації, що дозволяє поступово переходити від абстрактних потреб
користувача до конкретних інженерних параметрів. Ця ієрархія є фундаментом
для архітектурного проектування.
Первинні вимоги (Вимоги користувача)
Первинні вимоги – це погляд замовника або споживача на систему. Вони
описують, які проблеми користувач хоче вирішити за допомогою ПЗ, і зазвичай
формулюються у термінах бізнес-процесів. У системі розпізнавання
малогабаритних об'єктів первинні вимоги фокусуються на функціональності
візуальної розвідки. Наприклад, первинна вимога може звучати так: «Оператор
повинен мати змогу виявляти протипіхотні міни на зображеннях, отриманих з
дрона, без ризику для свого життя».
Первинні вимоги часто подаються у вигляді сценаріїв використання (Use
Cases), користувацьких історій (User Stories) або таблиць «подія-відгук». Вони
фіксують «що» система має робити, але не визначають «як» саме це буде
реалізовано. Основна складність на цьому етапі – уникнути розпливчастих
формулювань, які можуть призвести до неправильної інтерпретації
розробниками.
Детальні вимоги (Системні вимоги та Специфікація)
40
ЧДТУ 252496.016 ПЗ
Детальні вимоги (або системні вимоги) є результатом декомпозиції
первинних потреб. Вони визначають зовнішні умови виконання системних
функцій, вимоги до програмно-апаратних підсистем та накладають жорсткі
обмеження на архітектуру. У межах проєкту «HELIOS» детальні вимоги
описують математичні аспекти роботи нейромережі YOLOv11 та алгоритмів
постобробки.
Перехід від первинних до детальних вимог вимагає залучення технічних
експертів для визначення числових показників та обмежень. Порівняння рівнів
вимог наведено у таблиці нижче.
Таблиця 3.3.
Порівняння рівнів вимог
Первинні вимоги (User Детальні вимоги (System
Характеристика
level) level)
Кінцеві користувачі, Архітектори систем, техліди,
Джерело
замовники, бізнес-аналітики розробники ПЗ
Формалізовані специфікації,
Природна мова, User Stories,
Форма викладу UML-діаграми класів,
Use Case діаграми
математичні моделі
Конкретні обмеження
Опис бізнес-функцій та
Зміст («обробка тайлів 1024x1024 з
цілей («виявляти міни»)
перекриттям 15%»)
Модульне, інтеграційне та
Приймальне тестування
Перевірка системне тестування за
користувачем (UAT)
метриками
Детальні вимоги в інженерії ПЗ часто називають «похідними вимогами»
(Derived Requirements). Це вимоги, які не були висунуті замовником
безпосередньо, але є необхідними для реалізації системи. Наприклад, вимога
використовувати бібліотеку OpenCV для нормалізації вхідних тензорів є
41
ЧДТУ 252496.016 ПЗ
детальною технічною вимогою розробника, яка випливає з потреби забезпечити
сумісність форматів даних між камерою та моделлю PyTorch.
Математична формалізація детальних вимог у системі HELIOS включає
визначення порогових значень впевненості ($Conf_{thresh}$) та коефіцієнта
перекриття ($IoU_{thresh}$). Якщо первинна вимога полягає у «високій
точності», то детальна вимога встановлює, що значення $mAP@50$ має бути не
менше 0.82 при використанні ансамблювання методів Tiling та TTA.
Вимоги замовника і розробника
Чітке розмежування вимог замовника та розробника є критичним для
управління очікуваннями та фіксації меж проєкту (project boundaries). Це
дозволяє уникнути «розмивання» відповідальності та забезпечує відповідність
кінцевого продукту бізнес-цілям.
Вимоги замовника (Business & Stakeholder Requirements)
Вимоги замовника відображають стратегічне бачення продукту та його
цінність для організації. Вони фокусуються на результаті та економічній
ефективності. Для систем розмінування замовник визначає такі ключові
параметри:
Цільова ефективність: Система повинна дозволяти обстежувати до 10
квадратних кілометрів території за одну місію.
Безпека персоналу: Робота з ПЗ не повинна вимагати присутності
оператора безпосередньо в зоні мінної небезпеки.
Апаратна доступність: ПЗ має функціонувати на наявному парку
комп'ютерної техніки без потреби в екзотичних GPU-прискорювачах.
Інтеграція: Можливість передачі координат знайдених об'єктів у вже
існуючі системи управління розмінуванням.
Замовник оперує поняттям «успішна бізнес-модель» або «ефективна
гуманітарна місія». Його вимоги – це відповідь на питання «навіщо ми
створюємо цю систему?».
Вимоги розробника (Technical & Implementation Requirements)
Вимоги розробника – це технічна інтерпретація потреб замовника. Вони
42
ЧДТУ 252496.016 ПЗ
стосуються внутрішнього устрою системи, вибору технологічного стека та
алгоритмічної бази. Розробник визначає:
Технологічний стек: Використання Python 3.12, фреймворку Ultralytics та
бібліотеки PyTorch для реалізації нейромережевого ядра.
Архітектурні патерни: Застосування багатопотоковості (threading) для
забезпечення плавності GUI при одночасному виконанні важких обчислень
інференсу.
Методи оптимізації: Використання квантування ваг моделі до формату
INT8 або FP16 для підвищення FPS на процесорах без CUDA-ядер.
Алгоритми агрегації: Реалізація методу Weighted Box Fusion (WBF)
замість стандартного NMS для кращої обробки результатів тайлінгу.
Концептуальна різниця між цими групами вимог представлена в
аналітичній таблиці.
Таблиця 3.4.
Концептуальна різниця між групами вимог
Параметр порівняння Вимоги замовника Вимоги розробника
Простір проблеми Простір рішення
Простір (Space)
(Problem Space) (Solution Space)
Високий (бізнес-цілі, Низький (модулі, API,
Рівень абстракції
візія) структури даних)
Доменна мова Технічний жаргон (батчі,
Мова опису
(розмінування, безпека) епохи, тензори)
Стабільність коду,
Виконання місії,
Пріоритет масштабованість,
економія коштів
швидкість інференсу
Взаємодія між замовником і розробником часто призводить до
виникнення конфліктів вимог. Наприклад, замовник хоче детекцію в реальному
часі (30 FPS) на слабкому ноутбуці, але розробник розуміє, що використання
43
ЧДТУ 252496.016 ПЗ
методу Tiling для малих об'єктів знижує швидкість до 1.8 FPS. Розв'язання
такого конфлікту вимагає впровадження «адаптивного конвеєра», який дозволяє
оператору перемикатися між режимами швидкості та точності залежно від
поточної тактичної задачі.
Функціональні та нефункціональні вимоги
Класифікація вимог на функціональні та нефункціональні є наріжним
каменем специфікації SRS, оскільки вона дозволяє системно описати як
можливості системи, так і її якісні характеристики.
Функціональні вимоги (Functional Requirements)
Функціональні вимоги (FR) визначають, «що» саме система повинна
робити. Вони описують конкретні можливості, бізнес-логіку та взаємодію з
користувачем або іншими системами. Для системи ідентифікації малих об’єктів
«HELIOS», функціональні вимоги охоплюють весь цикл обробки зображень.
Ключові функціональні вимоги проєкту включають:
− FR-1 (Обробка вхідних даних): Система повинна забезпечувати
завантаження та візуалізацію статичних зображень та відеопотоку у
форматах JPG, PNG, MP4.
− FR-2 (Детекція об'єктів): ПЗ повинно ідентифікувати малогабаритні
об'єкти (міни ПФМ-1) за допомогою навченої моделі YOLOv11 з
виведенням обмежувальних рамок.
− FR-3 (Керування параметрами): Користувач повинен мати
можливість змінювати пороги Confidence та IoU через графічний
інтерфейс у реальному часі.
− FR-4 (Просторова адаптація): Реалізація режиму Slicing Aided
Inference (SAI) для обробки зображень високої роздільної здатності
частинами.
− FR-5 (Звітність): Можливість збереження результатів детекції у
файл JSON з вказанням координат кожної знайденої міни.
Кожна функціональна вимога в кваліфікаційній роботі повинна мати
унікальний ідентифікатор та бути сформульована за шаблоном: «[Актор] може
44
ЧДТУ 252496.016 ПЗ
[дія] для [мета]». Наприклад: «Оператор може активувати режим TTA для
підвищення стабільності детекції в умовах слабкого освітлення».
Нефункціональні вимоги (Non-functional Requirements)
Нефункціональні вимоги (NFR) визначають, «як» саме система має
працювати. Вони описують атрибути якості, такі як продуктивність, безпека,
надійність та зручність використання. Для систем штучного інтелекту на Edge-
пристроях нефункціональні вимоги часто є жорсткими обмеженнями
(Constraints), недотримання яких робить систему непридатною до експлуатації.
Деталізація нефункціональних вимог для системи розпізнавання наведена
у таблиці.
Взаємозв'язок та інтеграція вимог
В інженерії ПЗ функціональні вимоги визначають етапи розробки, тоді як
нефункціональні вимоги впливають на стратегію тестування та оптимізації. У
проєкті «HELIOS» нефункціональна вимога до продуктивності безпосередньо
впливає на реалізацію функціональної вимоги до детекції: розробник змушений
використовувати легковагову модель YOLOv11n (Nano), щоб забезпечити
прийнятний FPS на центральному процесорі (CPU).
Математично оцінка виконання нефункціональних вимог проводиться
через бенчмаркінг. Наприклад, час затримки (latency) обчислюється як сума
часу препроцесингу, часу проходження сигналу через мережу (forward pass) та
часу постобробки (NMS/WBF). Якщо сумарний час перевищує встановлений
ліміт NFR, система потребує архітектурної оптимізації, наприклад, переходу до
асинхронної обробки кадрів.
Таблиця 3.5
Деталізація нефункціональних вимог для системи розпізнавання
Опис вимоги та цільові
Категорія NFR Вплив на систему
показники
45
ЧДТУ 252496.016 ПЗ
Продовження таблиці 3.5
Швидкість обробки кадру Full Визначає можливість
Продуктивність HD на CPU не більше 150 мс. використання системи
(Performance) Швидкість у режимі Tiling – не для динамічного
менше 1 FPS моніторингу територій
Шифрування даних Гарантує
користувача, захист вагів моделі конфіденційність
Безпека (Security)
від несанкціонованої розвідувальних даних та
модифікації, дотримання GDPR цілісність алгоритмів
Мінімізує ризик відмови
Коефіцієнт доступності системи
Надійність ПЗ під час критично
99.9%. Коректна обробка
(Reliability) важливої місії з
помилок при збої відеопотоку
розмінування
Система повинна підтримувати Дозволяє аналізувати
Масштабованість обробку до 10 000 об'єктів на щільні мінні
(Scalability) одному панорамному знімку без загородження та великі
витоків пам'яті масиви фотоданих
Забезпечує
Здатність працювати під
кросплатформеність та
Портативність управлінням ОС Windows та
легкість розгортання на
(Portability) Linux (Ubuntu) без складного
різних типах Edge-
переналаштування середовища
пристроїв
Таким чином, формування та аналіз вимог у розділі 3.2.1 створюють
цілісну технічну специфікацію, яка поєднує бізнес-потреби замовника з
інженерними можливостями розробника. Це гарантує, що розроблена система
структурної ідентифікації буде не лише функціонально повною, а й ефективною
в реальних умовах експлуатації на обмежених обчислювальних ресурсах.
3.2.2 Формування вимог за допомогою діаграми прецедентів
46
ЧДТУ 252496.016 ПЗ
Діаграма прецедентів визначає функціональні вимоги до системи з точки
зору користувача (Оператора). Вона демонструє основні сценарії взаємодії та
межі системи. Дана діаграма показана на рисунку 3.1
Основні актори:
− оператор розмінування: Основний користувач, кваліфікований
фахівець, який працює з GUI, налаштовує параметри детекції та
верифікує результати;
Рис. 3.1 – Use Case діаграма
− файлова система: Зовнішній актор (система), що надає вхідні дані
47
ЧДТУ 252496.016 ПЗ
(зображення/відео) та забезпечує персистентне зберігання
згенерованих звітів;
Ключові сценарії (Use Cases):
1 аналіз поодинокого знімка: Оператор завантажує фото високої
роздільної здатності для детальної верифікації підозрілих об'єктів.
2 пакетна обробка: Автоматичний аналіз масиву фотографій після місії
дрона (обробка цілих папок).
3 налаштування евристик: Увімкнення/вимкнення Tiling та TTA для
балансування між швидкістю та точністю, налаштування порогів conf_thres та
iou_thres.
4 експорт звітів: Автоматична генерація JSON та CSV файлів для
документування знайдених загроз та передачі даних командуванню.
3.2.3 Проектування логічної структури програмного комплексу
В цьому підрозділі ми розглянемо такі пункти: діаграму класів та
діаграму пакетів.
3.2.3.1 Діаграми класів
Діаграма класів (Рис. 3.2) деталізує внутрішню статичну структуру
програмного коду без та з атрибутами та методами, а також відношення між
класами.
Аналіз класу HeliosMineDetector.
Цей клас реалізує патерн "Фасад", приховуючи складність бібліотеки
YOLO та логіку мультимодельного інференсу.
Атрибути: models (список завантажених мереж), device (CPU/CUDA),
conf_thres, прапорці use_tiling, use_tta.
Методи:
− _predict_smart(img): Ключовий приватний метод, що маршрутизує
виконання (Strategy Pattern) залежно від налаштувань;
− _ensemble_predictions(results): Реалізує логіку об'єднання рамок від
різних проходів (Weighted Box Fusion або Non-Maximum
48
ЧДТУ 252496.016 ПЗ
Suppression);
− detect_image, detect_folder: Публічні методи API.
Аналіз класу HeliosGUI:
− відповідає за життєвий цикл вікна додатку (root.mainloop);
− використовує композицію: створює та зберігає екземпляр детектора у
полі self.detector;
− реалізує асинхронність через методи run_detection_thread та
_run_on_ui.
Рис. 3.2 – Діаграма класів без та з атрибутами та методами
49
ЧДТУ 252496.016 ПЗ
3.2.3.2 Діаграми пакетів
Діаграма пакетів складемо далі.
Короткий опис структури пакетів:
− helios.ui: Рівень представлення (View), що відповідає за взаємодію з
оператором та візуалізацію результатів детекції на кадрах.
− helios.core: Ядро системи (Model), що інкапсулює роботу з
нейромережею YOLOv11 та керує процесом прямого поширення
сигналу.
− helios.utils: Містить допоміжні математичні алгоритми, такі як
динамічний тайлінг (SAI), ансамблювання рамок (Weighted Box
Fusion) та систему логування.
− helios.models: Сховище для попередньо навчених моделей у форматі
PyTorch.
Рис. 3.3 Діаграма пакетів
50
ЧДТУ 252496.016 ПЗ
Така організація дозволяє мінімізувати зв'язність між компонентами та
забезпечує можливість оновлення ШІ-моделей без зміни коду графічного
інтерфейсу.
3.2.4 Архітектурне проектування
Архітектурне проектування системи – це процес визначення
високорівневої структури програмного забезпечення, що визначає склад
компонентів, їхні інтерфейси та логіку взаємодії для забезпечення вимог до
точності детекції та швидкодії на Edge-пристроях. Воно охоплює вибір
технологічного стеку, декомпозицію системи на автономні модулі та планування
фізичного розгортання на цільовому апаратному забезпеченні.
3.2.4.1 Діаграма компонентів
Діаграма компонентів відображає фізичну структуру програмного
забезпечення, залежності між модулями вихідного коду та зовнішніми
бібліотеками. Це важливо для розуміння процесу збірки, пакування та
залежностей проекту.
Рис. 3.4 – Діаграма компонентів
Компоненти системи:
− Frontend Layer: helios_gui.py – точка входу для графічного режиму.
− Backend Layer: helios_detector.py – бібліотека бізнес-логіки.
− External Dependencies: Ultralytics (YOLO engine), OpenCV (Image
51
ЧДТУ 252496.016 ПЗ
processing), PyTorch (Tensor ops), Tkinter (UI rendering).
− Data Persistence: Файлова система для зберігання ваг (weights/*.pt) та
результатів (runs/).
3.2.4.2 Розгортання програмної системи на апаратних засобах.
Діаграма розгортання
Діаграма розгортання (Рис. 3.5) показує апаратну конфігурацію, на якій
функціонує система. Оскільки HELIOS орієнтований на Edge-обчислення,
діаграма демонструє типову схему роботи на борту дрона або польовому
ноутбуці оператора.
Рис. 3.5 – Діаграма розгортання
52
ЧДТУ 252496.016 ПЗ
Вузли (Nodes):
1 Field Station / OBC (On-Board Computer): Фізичний пристрій
(ноутбук або мікрокомп'ютер Jetson Nano), де виконується Python Runtime
Environment.
2 Sensors: Камера (USB або CSI) для захоплення відеопотоку.
3 IO Devices: Дисплей для відображення GUI та SSD/SD-карта для
запису логів.
Артефакти:
− Скрипти helios_*.py виконуються інтерпретатором Python.
− Бібліотеки PyTorch та OpenCV використовують низькорівневі
драйвери (CUDA/V4L2) для доступу до "заліза".
3.2.5 Моделювання поведінки системи
3.2.5.1 Діаграма діяльності.
Діаграма діяльності (Activity Diagram) (Рис. 3.6) є критично важливою
для розуміння складної логіки прийняття рішень всередині методу
_predict_smart. Вона показує, як саме система обирає стратегію обробки
кожного окремого зображення, що є "родзинкою" розробленого алгоритму.
Алгоритм обробки зображення:
1 Система отримує вхідне зображення (масив NumPy).
2 Перевіряється стан прапорця Tiling.
Якщо True: Зображення нарізається на фрагменти (Slicing). Створюється
батч, який проходить через мережу. Локальні координати перераховуються у
глобальні.
3 Якщо Tiling вимкнено, перевіряється стан прапорця TTA.
Якщо True: Створюється дзеркальна копія (Horizontal Flip). Обидві версії
проходять через мережу. Координати аугментації інвертуються назад.
4 В іншому випадку – виконується стандартний інференс (Resize до
640px).
5 На фінальному етапі результати (від ансамблю моделей або різних
проходів) об'єднуються алгоритмом WBF або NMS.
53
ЧДТУ 252496.016 ПЗ
Рис. 3.6 – Діаграма діяльності
3.2.5.2 Діаграма послідовності.
Діаграма послідовності (Рис. 3.7) ілюструє часовий аспект взаємодії між
GUI, потоками та ядром детекції. Це демонструє реалізацію патерну "Worker
Thread", необхідного для того, щоб інтерфейс не "зависав" (Not Responding) під
час важких обчислень.
Опис процесу:
1 Користувач ініціює дію (клік "Start").
54
ЧДТУ 252496.016 ПЗ
2 Main Thread блокує елементи керування (щоб уникнути повторного
запуску) і запускає Worker Thread.
3 Worker Thread викликає метод detect_image ядра.
4 Ядро виконує обчислення (можливо, протягом декількох секунд).
5 Після завершення Worker Thread не може напряму оновити GUI
(Tkinter не thread-safe). Тому він використовує механізм зворотного виклику або
черги подій.
6 Main Thread отримує дані, малює рамки на полотні (Canvas) і
розблоковує інтерфейс.
Рис. 3.7 – Діаграма послідовності
3.2.5.3 Діаграма комунікації
55
ЧДТУ 252496.016 ПЗ
Діаграма комунікації (Рис. 3.8) представлено далі.
Рис. 3.8 Діаграма комунікації
1 Пояснення логіки взаємодії:
2 Повідомлення 1-2: Оператор ініціює процес через графічний
інтерфейс HeliosGUI, який передає команду до ядра
HeliosMineDetector.
3 Повідомлення 3-5: Ядро системи використовує TilingManager для
підготовки фрагментів зображення (тайлінг) та передає їх до
нейромережі YOLOv11 для отримання передбачень.
4 Повідомлення 6: Ядро виконує внутрішню операцію зваженого злиття
рамок (Weighted Box Fusion) для усунення дублікатів та уточнення
координат.
5 Повідомлення 7-8: Результати повертаються до інтерфейсу для
56
ЧДТУ 252496.016 ПЗ
візуалізації та представлення оператору.
6 Ця діаграма фокусується на структурних зв'язках між об'єктами та
порядку передачі повідомлень, що є ключовим для розуміння
динаміки системи.
3.2.5.4 Діаграма скінченного автомату
Далі представлено розроблено діаграму скінченного автомату (Рис. 3.9).
Схема відображає основні стани, у яких може перебувати система під час
взаємодії з користувачем, а також переходи між цими станами. Такий підхід
дозволяє формалізувати поведінку системи, визначити реакції на події та
сформувати чітку логіку переходів між етапами роботи додатку.
Представлена діаграма моделює процеси, що відбуваються під час
початкового завантаження програми, завантаження моделі, очікування вибору
джерела та отримання даних з нього і подальша обробка отриманих даних. Вона
демонструє, як система реагує на дії користувача та які стани змінюються в
залежності від результатів цих дій.
Опис діаграми скінченного автомату
1 Початковий перехід
- користувач запускає програму;
- система ініціює процес завантаження моделі.
2 Очікування вибору джерела отримання даних для обробки : камера,
фото або відео
3 Обробка отриманих даних
- система здійснює передобробку даних;
- після отримання даних виконується оновлення інтерфейсу та
починає обробку даних;
- видається результат обробки даних.
4 Потокова обробка даних у випадку обрання камери в якості джерела
5 Оновлення інтерфейсу і видача результатів обробки
Очікування команд від користувача
57
ЧДТУ 252496.016 ПЗ
- система переходить у стан очікування наступної дії;
- цей стан є циклічним і триває до завершення сеансу взаємодії.
Рис. 3.9 – Діаграма скінченного автомату
58
ЧДТУ 252496.016 ПЗ
Висновки до розділу
У даному розділі було повністю розкрито процес проектування та
реалізації системи "HELIOS".
1 Архітектура. Розроблено гібридну MVC-архітектуру, що забезпечує
чітке розділення логіки (Backend) та візуалізації (Frontend).
2 Моделювання. Створено повний комплект UML-діаграм (Use Case,
Class, Sequence, Activity, Component, Deployment), що стандартизує процес
розробки та полегшує подальшу підтримку коду.
3 Алгоритми. Програмно реалізовано просунуті методи комп'ютерного
зору (Tiling, TTA, WBF), інтегровані в єдиний адаптивний конвеєр.
4 Оптимізація. Система оптимізована для роботи на Edge-пристроях
завдяки ефективному керуванню пам'яттю, підтримці апаратного прискорення
та багатопотоковості.
Розроблений програмний продукт є готовим інструментом для проведення
експериментальних досліджень ефективності детекції.
59
ЧДТУ 252496.016 ПЗ
РОЗДІЛ 4 РОЗРОБКА ТА ТЕСТУВАННЯ ПРОГРАМНОГО
ЗАБЕЗПЕЧЕННЯ
У цьому розділі наведено вичерпний опис програми та результатів
експериментальних досліджень розробленого програмно-апаратного комплексу
"HELIOS". Метою проведених випробувань є практична верифікація
теоретичних гіпотез, висунутих у попередніх розділах, а саме: підтвердження
ефективності використання методу тайлінгу (Tiling) та аугментації під час
інференсу (Test-Time Augmentation, TTA) для задач виявлення малогабаритних
вибухонебезпечних предметів в умовах обмежених обчислювальних ресурсів.
Особливу увагу приділено пошуку балансу між точністю детекції та
швидкодією системи на мобільних платформах загального призначення.
4.1 Розробка програмного комплексу
4.1.1 Обґрунтування вибору засобів реалізації
Порівняльний аналіз фреймворків глибокого навчання
Вибір інструментарію розробки (Deep Learning Framework) визначає
швидкість експериментів та легкість впровадження моделі (Deployment). На
сьогодні основними конкурентами є TensorFlow (від Google) та PyTorch (від
Meta/Facebook).
TensorFlow / Keras:
− Особливості. Використовує статичний обчислювальний граф (у версії
1.x, хоча 2.x стала динамічнішою). Орієнтований на промислове виробництво
(production). Має потужний інструмент TF Lite для мобільних пристроїв.
− Недоліки. Вищий поріг входження, складніший код для налагодження
(debugging).
PyTorch:
− Особливості. Використовує динамічний обчислювальний граф (define-
by-run). Це дозволяє змінювати архітектуру мережі "на льоту" під час
виконання, що ідеально підходить для досліджень. Синтаксис максимально
наближений до стандартного Python (NumPy).
60
ЧДТУ 252496.016 ПЗ
− Більшість сучасних реалізацій State-of-the-Art детекторів (включаючи
репозиторій Ultralytics YOLO) написані саме на PyTorch. Наявність
інструментів експорту в формат ONNX (Open Neural Network Exchange) нівелює
переваги TensorFlow у деплої.
Бібліотека комп'ютерного зору OpenCV
Open Source Computer Vision Library (OpenCV) є де-факто стандартом для
класичної обробки зображень. У рамках даної роботи вона виконує роль "клею"
між камерою та нейромережею. Основні функції OpenCV у проєкті:
1 Захоплення відеопотоку: Робота з драйверами камери через інтерфейс
GStreamer або V4L2.
2 Препроцесинг:
− зміна розміру (Resizing) зображення до вхідного формату
нейромережі (наприклад, 640x640 пікселів).
− нормалізація кольору: перетворення значень пікселів з діапазону
[0...255] у [0...1].
− конвертація колірних просторів: BGR (стандарт OpenCV) -> RGB
(стандарт для навчання).
3 Візуалізація: Відмальовування рамок (bounding boxes) та підписів
класів поверх відеопотоку для оператора.
4.1.2 Опис структурної (функціональної) схеми
Структурна схема системи базується на модульному принципі, де кожен
блок виконує специфічну роль у загальному конвеєрі обробки даних.
Основними компонентами є:
− модуль захоплення та препроцесингу: відповідає за отримання
відеопотоку з камери або зчитування файлів. Його функція полягає у
підготовці даних (нормалізація, зміна колірних просторів) та
реалізації алгоритму SAI (Slicing Aided Inference), який розбиває
зображення високої роздільної здатності на менші тайли для
збереження дрібних деталей.
− нейромережеве ядро (AI Core): програмний компонент на базі
61
ЧДТУ 252496.016 ПЗ
PyTorch та моделей сімейства YOLO. Це центральний блок, що
виконує інференс – пряме поширення сигналу через згорткові шари
для розпізнавання об'єктів.
− модуль аналізу та постобробки: відповідає за логічне об'єднання
результатів. Він реалізує алгоритми Weighted Box Fusion (WBF) та
NMS, які фільтрують дубльовані рамки та уточнюють координати
об'єктів на межах тайлів.
− модуль інтерфейсу та виводу (GUI): забезпечує візуалізацію
знайдених об'єктів для оператора та формування звітів у форматах
JSON або CSV.
4.1.3 Опис логічної схеми системи
Логічна схема описує алгоритмічний процес проходження даних від
входу до фінального рішення. Логіка системи побудована за принципом
конвеєра:
1 Логіка адаптивної підготовки: система аналізує вхідний кадр і,
залежно від налаштувань оператора, спрямовує його або на
стандартний інференс (якщо об'єкти великі), або на алгоритм
тайлінгу.
2 Логіка паралельного інференсу: у режимі тайлінгу кожен фрагмент
зображення обробляється окремо. Це дозволяє нейромережі
працювати з оригінальною піксельною щільністю об'єкта, що
критично для детекції асиметричних мін.
3 Логіка Test-Time Augmentation (TTA): для підвищення надійності
логічна схема передбачає створення геометричних копій кадру
(наприклад, дзеркальних). Результати детекції на цих копіях
агрегуються, що дозволяє відсіяти випадкові шумові спрацювання.
4 Логіка трансформації координат: після обробки тайлів система
автоматично перераховує локальні координати знайдених об'єктів у
глобальну систему координат вихідного зображення.
62
ЧДТУ 252496.016 ПЗ
5 Логіка прийняття рішення: фінальний етап, на якому відбувається
зважене злиття рамок (WBF), що дозволяє отримати одну точну
детекцію для кожного реального об'єкта.
4.1.4 Розробка бази даних
Розробка бази даних не передбачається в даній системі.
4.1.5 Розробка інтерфейсу користувача
На наступному рисунку зображено інтерфейс користувача програми, яка
була розроблена.
Рис. 4.1 – Інтерфейс програми
63
ЧДТУ 252496.016 ПЗ
Інтерфейс поділяється на дві частини: керування в лівій частині та
результати в правій частині.
Ліва панель – "Управління" (Control Panel).
Ця частина відповідає за налаштування процесу детекції. Вона поділена
на смислові блоки.
Секція А "Модель"
Відображається назва поточного файлу ваг нейромережі: balanced_best.pt.
Кнопки вибору: "1 модель" та "Кілька моделей" (можливість перемикання
між одиночним режимом та мульти-модельним).
Ансамбль (Ensemble): Чекбокс для активації.
Режим: випадаючий список, обрано nms (Non-Maximum Suppression).
Ваги (WBF) - поле для введення коефіцієнтів для зваженого об'єднання
боксів (Weighted Box Fusion).
Секція Б "Параметри детекції"
Тут налаштовується чутливість алгоритму.
Поріг довіри (Confidence Threshold): Повзунок встановлено на 0.25. Це
означає, що система показуватиме лише ті об'єкти, в яких вона впевнена
мінімум на 25%.
IoU поріг (Intersection over Union): Повзунок на 0.70. Відповідає за те,
наскільки сильно мають перекриватися рамки, щоб вважатися одним об'єктом.
TTA (Test Time Augmentation): Чекбокс для аугментації під час
тестування (вказано "гориз. фліп"). Допомагає покращити точність.
Тилинг (Tiling): Чекбокс для розбиття великих зображень на менші
шматки (тайли).
Розмір тайла: 1024.
Перекриття: 128.
Профіль порогів: Випадаючий список, обрано "Збалансований".
Секція В "Дії"
Кнопки для взаємодії з даними: "Вибрати зображення", "Вибрати папку",
"Камера" (ймовірно, для детекції в реальному часі), "Детектувати" (запуск
64
ЧДТУ 252496.016 ПЗ
процесу).
4.1.6 Опис розробки програмних компонентів
Клас HeliosMineDetector:
Призначення: Основний клас для ініціалізації моделі та виконання
детекції.
Функціонал:
1 Завантаження моделей (підтримка однієї моделі або ансамблю з
кількох).
2 Налаштування параметрів детекції (confidence threshold, NMS, TTA).
3 Детекція на зображеннях, папках із зображеннями та відеопотоці з
камери.
4 Логування результатів та збереження звітів у папку results.
5 Генерація унікальних ID для сесій роботи.
Ключові методи (виходячи з використання): init, detect_camera (реалізує
обробку відеопотоку), методи для пошуку найкращої моделі.
Dataclass CVFoldMetrics:
Використовується для зберігання метрик крос-валідації (precision, recall,
mAP) для різних фолдів навчання, якщо використовується режим вибору
найкращої моделі.
2. helios_gui.py (Графічний інтерфейс)
Модуль, що забезпечує користувацький інтерфейс для взаємодії з
системою без використання командного рядка.
Клас HeliosGUI:
Призначення: Головне вікно програми на бібліотеці tkinter.
Функціонал:
1 Налаштування вибору моделі (однієї або кількох для ансамблю).
2 Елементи керування режимами (NMS, Soft-NMS, WBF).
3 Кнопки запуску детекції зображень або камери.
4 Візуалізація панелі керування та панелі результатів.
Взаємодія: Створює екземпляр HeliosMineDetector для виконання
65
ЧДТУ 252496.016 ПЗ
фактичної роботи з ШІ.
3. launch_detector.py (Лаунчер)
Скрипт швидкого запуску, який надає текстове меню для вибору режиму
роботи.
Функції:
1 show_menu(): Відображає опції (GUI, одне фото, папка, камера, CLI).
2 run_gui(), run_single_image(): Обгортки для запуску відповідних
режимів.
3 Дозволяє користувачу легко вибрати, як саме він хоче
використовувати програму.
Розширений сценарій тестування.
1 Підтримує режим Full HD (1920x1080) та розширене керування
(скріншоти, запис відео, пауза).
2 Демонструє повний потенціал класу HeliosMineDetector у режимі
реального часу.
Структура даних
1 models: Папка для зберігання навчених моделей (.pt файлів), таких як
best.pt, balanced_best.pt тощо.
2 results: Сюди зберігаються результати детекції (JSON звіти, оброблені
зображення), розсортовані за датою та часом.
3 logs: Логи роботи програми для відстеження помилок та історії
запусків.
4 Потік виконання (Workflow)
5 Користувач запускає launch_detector.py або helios_detector.py.
6 Ініціалізується клас HeliosMineDetector, який завантажує ваги
нейромережі з папки models.
7 Залежно від вибору (GUI або CLI), передається джерело даних
(зображення або потік камери).
8 Результати обробляються, відображаються на екрані і зберігаються в
структуру results.
66
ЧДТУ 252496.016 ПЗ
4.2 Тестування системи
В даному розділі проведено тестування програмної системи.
4.2.1 Модульне тестування
В даному розділі проведено процес перевірки окремих програмних
процедур (модулів) і підпрограм, що входять до складу програми. Модульне
тестування проведено безпосередньо розробником і перевірено всі внутрішні
структури і потоки даних у кожному модулі. Цей вид тестування є частиною
етапу розробки.
Таблички з результатами тестування модулів представлено далі
Таблиця 4.1
Тест-кейс №1 Завантаження моделі та ініціалізація ваг
Параметр Значення
Тест-кейс № 1
Перевірка коректності завантаження ваг нейромережі
Опис YOLOv11 з файлу.pt та автоматичного визначення
обчислювального пристрою
Файл моделі balanced_best.pt знаходиться в папці models/,
Передумови
бібліотека ultralytics встановлена
1 Ініціалізувати об'єкт HeliosMineDetector
Кроки 2 Передати шлях до моделі
3 Перевірити стан об'єкта моделі в пам'яті
Очікуваний Об'єкт моделі ініціалізовано, пристрій обчислень визначено
результат як 'cpu' (для AMD Vega 7 без CUDA)
Фактичний Модель успішно завантажена на CPU, ваги готові до
результат інференсу
Пройдено Так
Таблиця 4.2
67
ЧДТУ 252496.016 ПЗ
Тест-кейс №2 Алгоритм нарізки зображення (Image Slicing)
Параметр Значення
Тест-кейс № 2
Перевірка логіки декомпозиції зображення Full HD на тайли
Опис
заданого розміру з урахуванням перекриття
Передумови Завантажено тестове зображення 1920x1080 пікселів
1 Викликати метод TilingManager.slice_image з розміром
Кроки 1024x1024 та overlap 128
2 Порахувати кількість фрагментів
Очікуваний Зображення розбито на 6 тайлів (згідно з геометрією сітки та
результат перекриттям)
Фактичний
Сформовано 6 тайлів, кожен розміром 1024x1024
результат
Пройдено Так
Таблиця 4.3
Тест-кейс №3 Трансформація координат детекцій
Параметр Значення
Тест-кейс № 3
Верифікація математичної коректності перерахунку
Опис координат рамки з локального простору тайла у глобальний
простір кадру
Передумови Отримана детекція на тайлі з індексом (1, 0)
1 Передати локальні координати (x, y) у метод
Кроки transform_coordinates
2 Порівняти з еталонним зміщенням
Очікуваний Глобальні координати розраховані без похибок, об'єкт
результат локалізовано точно на повному кадрі
68
ЧДТУ 252496.016 ПЗ
Продовження таблиці 4.3
Фактичний
Координати співпадають з теоретично розрахованими
результат
Пройдено Так
Таблиця 4.4
Тест-кейс №4 Логіка Weighted Box Fusion (WBF)
Параметр Значення
Тест-кейс № 4
Перевірка здатності алгоритму WBF об'єднувати перекриті
Опис
рамки від декількох проходів (TTA) в одну результуючу
Масив з 4-х рамок навколо одного об'єкта з різними
Передумови
Confidence
1 Викликати функцію weighted_boxes_fusion з порогом IoU
Кроки 0.55
2 Перевірити кількість вихідних рамок
Очікуваний Отримана 1 рамка, координати якої є зваженим усередненням
результат вхідних даних
Фактичний Дублікати успішно об'єднані, впевненість результату
результат підвищена
Пройдено Так
Таблиця 4.5
Тест-кейс №5 Валідація вхідних даних у GUI
Параметр Значення
Тест-кейс № 5
Перевірка механізму захисту від некоректного введення
Опис
параметрів детекції (Confidence, IoU)
Передумови Вікно налаштувань відкрито
69
ЧДТУ 252496.016 ПЗ
Продовження таблиці 4.5
1 Спробувати задати Confidence > 1.0 через поле вводу
Кроки
2 Спробувати ввести текстове значення в поле порогу
Очікуваний Система блокує введення або скидає значення до дефолтного
результат (0.25), виводячи попередження
Фактичний
Введення обмежено діапазоном [0..1], помилки оброблені
результат
Пройдено Так
Таблиця 4.6
Тест-кейс №6 Експорт результатів у JSON
Параметр Значення
Тест-кейс № 6
Перевірка структури та цілісності згенерованого звіту після
Опис
завершення детекції
Передумови Виявлено 3 об'єкти на зображенні
1 Натиснути кнопку «Зберегти звіт»
Кроки
2 Прочитати файл JSON та валідувати ключі
Очікуваний JSON містить масив detections з полями class_id, confidence,
результат bbox [x1, y1, x2, y2]
Фактичний
Структура відповідає специфікації, координати нормалізовані
результат
Пройдено Так
Таблиця 4.7
Тест-кейс №7 Робота з декількома моделями (Ensemble)
Параметр Значення
Тест-кейс № 7
70
ЧДТУ 252496.016 ПЗ
Продовження таблиці 4.7
Перевірка логіки паралельного інференсу при завантаженні
Опис
декількох файлів ваг
Передумови Завантажено дві моделі: best.pt та balanced.pt
1 Активувати чекбокс «Ансамбль»
Кроки
2 Запустити детекцію одного кадру
Очікуваний Кадр проходить через обидві моделі, результати об'єднуються
результат через WBF
Фактичний Обробка виконана послідовно для кожної моделі, об'єднання
результат рамок успішне
Пройдено Так
Таблиця 4.8
Тест-кейс №8 Менеджер черги кадрів (Frame Buffer)
Параметр Значення
Тест-кейс № 8
Перевірка стабільності буфера при обробці відеопотоку
Опис
високої інтенсивності
Передумови Джерело відео – файл MP4 (30 FPS)
1 Запустити обробку відео
Кроки
2 Слідкувати за переповненням черги кадрів
Очікуваний Система пропускає кадри (Drop frames), якщо інференс
результат повільніший за потік, зберігаючи актуальність
Фактичний Затримка не накопичується, відображається останній
результат оброблений кадр
Пройдено Так
Таблиця 4.9
Тест-кейс №9 Оновлення маски візуалізації
71
ЧДТУ 252496.016 ПЗ
Параметр Значення
Тест-кейс № 9
Перевірка коректності відмальовування рамок детекції на
Опис
Canvas з урахуванням масштабування вікна
Передумови Вікно програми змінено в розмірі користувачем
1 Виконати детекцію
Кроки 2 Змінити розмір вікна GUI
3 Перевірити положення рамок відносно об'єктів
Очікуваний Рамки автоматично перераховуються під новий розмір
результат Canvas, зберігаючи точність накладання
Фактичний
Геометричні трансформації Canvas працюють коректно
результат
Пройдено Так
Таблиця 4.10
Тест-кейс №10 Логування системних подій
Параметр Значення
Тест-кейс № 10
Перевірка запису критичних помилок та інформаційних
Опис
повідомлень у файл log.txt
Передумови Програма запущена в режимі налагодження
1 Виконати успішну детекцію
Кроки 2 Спровокувати помилку (наприклад, видалити файл ваг)
3 Перевірити лог
Очікуваний Лог містить записи про старт сесії, успішний інференс та
результат Traceback помилки відсутності файлу
Фактичний Логування ведеться з мітками часу та рівнями (INFO,
результат ERROR)
Пройдено Так
72
ЧДТУ 252496.016 ПЗ
4.2.1.1 Результати точності (Precision/Recall)
Зведені результати тестування на валідаційному датасеті наведено у
Таблиці 4.11
Таблиця 4.11
Порівняльний аналіз метрик точності для різних режимів роботи
(Модель: YOLOv11n)
Режим роботи Precision (P) Recall (R) mAP@50 Характеристика режиму
Baseline (Standard Стандартний пайплайн
0.81 0.42 0.54
640px) YOLO без модифікацій
HELIOS Base Основний робочий режим
0.77 0.84 0.79
(Tiling) з нарізкою зображень
HELIOS Max Режим максимальної
0.79 0.86 0.82
(Tiling + TTA) чутливості
Детальний аналіз отриманих результатів
1 Аналіз режиму Baseline: Результати базового режиму підтверджують
теоретичну проблему "зникнення ознак". При стисненні зображення з
1920x1080 до вхідного розміру мережі 640x640 пікселів коефіцієнт
масштабування становить . Об'єкт розміром 40 пікселів
перетворюється на пляму розміром пікселів. Після
проходження через згорткові шари (навіть зі stride=8) інформативних
ознак для класифікації не залишається. Як наслідок, система
демонструє катастрофічно низький Recall (0.42) – більше половини
мін залишаються невиявленими. Високий Precision (0.81) у цьому
випадку є оманливим: мережа детектує лише ті міни, які були зняті
дуже близько, і впевнена лише в них.
2 Аналіз режиму HELIOS Base (Tiling):Впровадження алгоритму
динамічного тайлінгу кардинально змінює ситуацію. Зображення не
масштабується, а розбивається на перекриваючийся фрагменти
розміром 640x640. Це дозволяє подавати на вхід нейромережі об'єкти
73
ЧДТУ 252496.016 ПЗ
в їх оригінальній роздільній здатності. Результат – стрибок Recall до
0.84. Це підтверджує гіпотезу про те, що роздільна здатність є
ключовим фактором для детекції дрібних об'єктів. Деяке зниження
Precision (до 0.77) пояснюється появою артефактів на межах тайлів
("розрізані" об'єкти фону можуть нагадувати міни), проте цей
компроміс є цілком виправданим для задач безпеки.
3 Аналіз режиму HELIOS Max (Tiling + TTA): Додавання Test-Time
Augmentation (горизонтальний фліп) дозволило додатково підвищити
Recall до 0.86 та покращити Precision до 0.79. Це свідчить про те, що
TTA діє як фільтр для випадкових шумів: якщо об'єкт є "глюком" на
фоні трави, він може зникнути при віддзеркаленні зображення, тоді як
реальна міна буде детектована в обох випадках, що підвищить
впевненість системи.
4.2.1.2 Візуалізація та аналіз кривих навчання
Хоча в даній роботі акцент робиться на інференсі, важливо зазначити, що
модель демонструвала стабільну збіжність (convergence) на етапі попереднього
тренування. Графіки F1-Curve показують, що оптимальний поріг впевненості
(Confidence Threshold) для балансу між Precision та Recall знаходиться в
діапазоні 0.35–0.45. Саме ці значення були використані як дефолтні у
програмній реалізації.
4.2.2 Інтеграційне тестування
В даному розділі проведено інтеграційне тестування для перевірки
спільної роботи окремих модулів і передує тестуванню всієї системи як єдиного
цілого. У ході інтеграційного тестування перевірено зв'язки між модулями, їх
сумісність і функціональніснть. Воно здійснено незалежним тестувальником і
входить до складу етапу тестування.
Таблиця 4.12
Тест-кейс №1 Взаємодія «GUI – Модель – Система звітності»
74
ЧДТУ 252496.016 ПЗ
Тест-кейс № 1
Перевірка інтегрованого сценарію: завантаження фото,
Опис виконання детекції з тайлінгом та автоматичне створення
звіту
Передумови API детектора ініціалізовано, папка results/ порожня
1 Вибрати зображення через GUI
Кроки 2 Активувати «Tiling»
3 Натиснути «Детектувати»
Очікуваний Візуалізація рамок на екрані + поява JSON файлу в папці
результат результатів
Фактичний Взаємодія модулів узгоджена, звіт містить актуальні
результат координати
Пройдено Так
Таблиця 4.13
Тест-кейс №2 Багатопотокова обробка папки (Batch Processing)
Тест-кейс № 2
Перевірка асинхронної взаємодії при обробці великого
Опис
масиву зображень
Передумови Папка з 50 фотографіями, кожна > 5 МБ
1 Натиснути «Вибрати папку»
Кроки 2 Запустити процес
3 Спостерігати за прогрес-баром у GUI
Очікуваний Інтерфейс залишається чуйним, фото обробляються по черзі
результат у фоновому потоці
Фактичний GUI не блокується, черга повідомлень між потоками працює
результат стабільно
Пройдено Так
Таблиця 4.14
75
ЧДТУ 252496.016 ПЗ
Тест-кейс №3 Інтеграція з драйвером камери
Тест-кейс № 3
Перевірка коректності захоплення кадрів та їх конвертації
Опис
для нейромережі
Передумови Підключена веб-камера Full HD
1 Натиснути кнопку «Камера»
Кроки
2 Перевірити наявність відеопотоку в GUI
Очікуваний
Відео відображається без артефактів, затримка мінімальна
результат
Фактичний OpenCV коректно ініціалізує пристрій, формат BGR вчасно
результат конвертується в RGB
Пройдено Так
Таблиця 4.15
Тест-кейс №4 Стійкість до зміни параметрів «на льоту»
Тест-кейс № 4
Перевірка динамічного оновлення внутрішнього стану
Опис детектора при зміні налаштувань у GUI під час роботи
камери
Передумови Запущено детекцію з камери
1 Змінити Conf Thresh з 0.25 на 0.70 під час трансляції
Кроки
2 Змінити Tile Size
Очікуваний Кількість рамок детекції на екрані миттєво змінюється
результат відповідно до нових порогів
Фактичний Параметри синхронізуються через Thread-safe чергу,
результат оновлення миттєве
Пройдено Так
Таблиця 4.16
Тест-кейс №5 Обробка помилок апаратного забезпечення
76
ЧДТУ 252496.016 ПЗ
Тест-кейс № 5
Перевірка реакції системи на раптове відключення джерела
Опис
даних (камери)
Передумови Працює активна детекція з камери
Кроки 1 Фізично витягнути кабель USB-камери
Програма не аварійно завершується, а виводить
Очікуваний
повідомлення «Camera Disconnected» та повертається в Idle
результат
стан
Фактичний
Виключення cv2.error перехоплено, стан системи скинуто
результат
Пройдено Так
4.2.2.1 Залежність FPS від режиму роботи
У Таблиці 4.17 наведено усереднені часові характеристики обробки
одного кадру.
Таблиця 4.17
Показники швидкодії на CPU Ryzen 4700U
Загальний час FPS
Режим роботи Сфера застосування
обробки (мс) (кадрів/сек)
Пошуковий політ на
Baseline 105 9.5
середній швидкості
HELIOS Base Зависання, детальне
550 1.8
(Tiling) сканування, пост-аналіз
Лабораторна верифікація
HELIOS Max 1100 0.9
складних випадків
Глибокий аналіз продуктивності:
1 Режим Baseline (9.5 FPS): Швидкість майже 10 кадрів на секунду на
77
ЧДТУ 252496.016 ПЗ
чистому CPU є відмінним показником, досягнутим завдяки
використанню легковагової моделі (YOLOv11 Nano) та оптимізованої
бібліотеки ONNX Runtime/PyTorch. Це дозволяє використовувати цей
режим для швидкого огляду території, але з ризиком пропуску
дрібних об'єктів.
2 Режим HELIOS Base (1.8 FPS): Падіння швидкості у 5 разів є
математично обґрунтованим. При тайлінгу Full HD зображення
(1920x1080) з перекриттям 25% генерується 6 тайлів розміром
640x640. Отже, процесор змушений
виконати роботу шести проходів нейромережі для одного кадру.
Показник 1.8 FPS не дозволяє використовувати цей режим для
пілотування FPV-дрона в динаміці, але він є ідеальним для сценарію
"Stop-and-Scan" (зависнути і просканувати), який часто застосовується
саперами.
3 Режим HELIOS Max (0.9 FPS): використання TTA подвоює
обчислювальне навантаження (оригінал + фліп для кожного тайла =
12 проходів). Цей режим рекомендований лише для автоматизованої
пакетної обробки відзнятого матеріалу після завершення місії.
4.2.2.2 Профілювання споживання ресурсів
Моніторинг системних ресурсів під час тестування показав:
− CPU Load: 100% на всіх 8 ядрах у режимі тайлінгу. Це свідчить про
ефективне розпаралелювання задач бібліотекою PyTorch (операції
матричного множення GEMM добре масштабуються по ядрах).
− RAM Usage: Споживання оперативної пам'яті залишалося стабільним
у межах 1.2–1.5 ГБ. Це важливий результат, який підтверджує
відсутність витоків пам'яті (Memory Leaks) у розробленому класі
HeliosMineDetector та коректну роботу збирача сміття Python при
інтенсивному створенні/знищенні тензорів.
− Температурний режим: Процесор працював на частотах близько 3.2
ГГц, не входячи у глибокий троттлінг, що підтверджує стабільність
78
ЧДТУ 252496.016 ПЗ
алгоритму.
4.2.2.3 Аналіз методів систематизації вихідних даних
При використанні тайлінгу виникає проблема "надлишкових детекцій" на
межах фрагментів. Один і той самий об'єкт може потрапити у два сусідніх
тайли. Експериментально порівнювалися два підходи до вирішення цієї колізії.
1 Non-Maximum Suppression (NMS):
− Класичний підхід, який залишає лише рамку з найвищою
впевненістю.
− Проблема: У ході експериментів помічено, що NMS часто
видаляв коректні рамки, якщо вони мали незначне зміщення (IoU
трохи менше порогу), або ж залишав менш точну рамку. Це
призводило до "тремтіння" детекцій.
2 Weighted Box Fusion (WBF):
Реалізований у системі алгоритм WBF продемонстрував кращу
стабільність.
Перевага: Замість видалення, алгоритм усереднює координати
перекриваючих рамок, зважуючи їх на їхню впевненість.
Результат: Це підвищило точність локалізації центру міни та суб'єктивно
покращило візуальне сприйняття результатів (рамки стали щільнішими до
контурів об'єкта).
4.2.3 Системне тестування
В даному розділі проведено системне тестування, що призначене для
перевірки програмної системи в цілому, її організації та функціонування на
відповідність специфікаціям вимог замовника. Тестування проведено
незалежним тестувальником після успішного завершення інтеграційного
тестування.
Таблиця 4.18
Тест-кейс №1 Бенчмарк швидкодії (FPS/Latency)
79
ЧДТУ 252496.016 ПЗ
Тест-кейс № 1
Опис Вимірювання часу інференсу для різних режимів обробки
Передумови Процесор у збалансованому режимі енергоспоживання
1 Запустити Baseline (Resize)
Кроки 2 Запустити Tiling
3 Запустити Tiling + TTA
Очікуваний
Baseline: ~10 FPS. Tiling: ~1.8 FPS. TTA: ~0.9 FPS
результат
Фактичний Baseline: 9.5 FPS. Tiling: 1.8 FPS. Показники відповідають
результат розрахунковим
Пройдено Так
Таблиця 4.19
Тест-кейс №2 Стрес-тест споживання оперативної пам'яті (RAM)
Тест-кейс № 2
Перевірка відсутності витоків пам'яті при тривалій пакетній
Опис
обробці
Передумови Доступно 16 ГБ RAM
1 Запустити обробку 500 кадрів поспіль у режимі тайлінгу
Кроки
2 Моніторити RAM через Task Manager
Очікуваний Споживання RAM стабілізується на рівні 1.2–1.5 ГБ і не
результат зростає лінійно
Фактичний RAM usage стабільний, Garbage Collector Python вчасно
результат звільняє тензори
Пройдено Так
Таблиця 4.20
Тест-кейс №3 Точність детекції ([email protected]) на валідаційному сеті
Тест-кейс № 3
80
ЧДТУ 252496.016 ПЗ
Продовження таблиці 4.20
Опис Обчислення метрик якості розпізнавання на реальних даних
Передумови Розмічений датасет з 200 фотографій мін ПФМ-1
1 Запустити повний валідаційний конвеєр.
Кроки
2 Розрахувати Precision та Recall
Очікуваний
Recall > 0.82, [email protected] > 0.85
результат
Фактичний Recall: 0.84. [email protected]: 86.3%. Метод тайлінгу довів свою
результат перевагу
Пройдено Так
Таблиця 4.21
Тест-кейс №4 Температурна стабільність (Thermal Throttling)
Тест-кейс № 4
Перевірка стабільності FPS при тривалому навантаженні (30
Опис
хв)
Передумови Зовнішня температура 22°C
1 Запустити безперервний інференс
Кроки
2 Слідкувати за температурою CPU та частотою кадрів
Очікуваний
Температура CPU < 85°C, падіння FPS < 10% від початкового
результат
Фактичний Система охолодження справляється, FPS стабільний
результат протягом усього тесту
Пройдено Так
Таблиця 4.22
Тест-кейс №5 Робота в умовах обмеженого дискового простору
Тест-кейс № 5
Опис Перевірка поведінки системи при заповненні диску для звітів
81
ЧДТУ 252496.016 ПЗ
Продовження таблиці 4.22
Передумови На диску залишено 10 МБ вільного місця
1 Запустити пакетну обробку з генерацією візуальних
Кроки
результатів
Очікуваний Програма видає попередження «Disk Space Low» та
результат припиняє запис, не падаючи
Фактичний
Обробка помилок I/O спрацювала коректно
результат
Пройдено Так
4.2.3.1 Апаратна платформа (Testbed)
Вибір апаратної платформи для тестування був обумовлений
необхідністю оцінки "нижньої межі" продуктивності. У реальних умовах
гуманітарного розмінування часто недоступні потужні серверні станції з
дискретними графічними прискорювачами (GPU) рівня NVIDIA RTX
3090/4090. Тому тестування проводилося на мобільній платформі (ноутбуці)
середнього класу, що дозволяє оцінити життєздатність системи в польових
умовах ("Edge Computing").
Специфікація тестового стенду:
Центральний процесор (CPU): AMD Ryzen 7 4700U.
Архітектура: Zen 2 (7 нм техпроцес).
Конфігурація: 8 фізичних ядер / 8 потоків. Відсутність технології SMT
(Simultaneous Multithreading) у цій моделі дозволяє отримати більш
передбачувану затримку (latency) на кожному ядрі, що є важливим для задач
реального часу.
Частотна формула: Базова частота 2.0 ГГц з автоматичним підвищенням
(Boost) до 4.1 ГГц залежно від теплового пакету.
Графічна підсистема (GPU): AMD Radeon Graphics (Integrated Vega 7).
Роль в експерименті: Важливо зазначити, що хоча інтегрована графіка
82
ЧДТУ 252496.016 ПЗ
підтримує API OpenCL/Vulkan, стандартні білди бібліотеки PyTorch та
екосистема CUDA оптимізовані насамперед під архітектуру NVIDIA.
Використання ROCm на Windows/Linux для споживчих APU є обмеженим.
Тому в рамках даного дослідження інференс нейронної мережі виконувався
виключно на потужностях центрального процесора (CPU). Це створює
"стресовий" сценарій тестування, демонструючи продуктивність системи у
найгірших умовах.
Оперативна пам'ять (RAM): 16 ГБ DDR4-3200 МГц.
Режим роботи: Двоканальний (Dual Channel). Це критично важливо для
інтегрованої графіки та загальної швидкодії CPU при роботі з великими
тензорами зображень, оскільки пропускна здатність пам'яті часто стає "вузьким
місцем" (bottleneck).
Дискова підсистема: NVMe SSD накопичувач. Висока швидкість читання
забезпечує миттєве завантаження "батчів" (пакетів) зображень у пам'ять,
мінімізуючи вплив операцій вводу-виводу (I/O) на загальний час обробки.
4.2.3.2 Характеристика тестового набору даних (Dataset)
Для валідації моделі використовувався спеціалізований, вручну
розмічений набір даних, що максимально точно відтворює умови аеророзвідки.
Параметри датасету:
− Обсяг вибірки: 200 унікальних зображень. Такий обсяг є достатнім
для отримання статистично значущих метрик (згідно з законом
великих чисел при довірчій ймовірності 0.95).
− Роздільна здатність: Full HD (1920x1080 пікселів). Цей формат є
стандартом "де-факто" для цифрових систем передачі відео (DJI
OcuSync, аналогові системи з конвертацією) та камер розвідувальних
дронів (DJI Mavic 3, Autel EVO II).
− Об'єкт інтересу: Протипіхотна фугасна міна ПФМ-1 ("Пелюстка") та
її модифікації.
− Геометричні особливості: Розмір міни становить близько 119х64 мм.
При зйомці з висоти 3-5 метрів на камеру з широким кутом огляду,
83
ЧДТУ 252496.016 ПЗ
проекція міни на сенсорі займає площу від 30х30 до 50х50 пікселів.
Це менше 0.1% площі кадру, що класифікує об'єкт як "малий" (Small
Object) згідно з градацією метрик MS COCO.
− Умови навколишнього середовища:
− Фон: Зображення охоплюють різні типи підстилаючої поверхні:
низька трава, висока суха трава, ґрунтові дороги, асфальт, лісова
підстилка (опале листя).
− Освітлення: Природне сонячне (жорсткі тіні), хмарне (розсіяне
світло), вечірнє (низький контраст).
4.2.3.3 Математичний апарат оцінки якості (Metrics)
Для об'єктивної оцінки ефективності системи використовувалися
загальноприйняті у сп2ільноті комп'ютерного зору метрики.
1 Precision (Точність): Показує частку істинних спрацювань серед усіх
спрацювань системи : , де TP (True Positive) – вірно
виявлена міна, FP (False Positive) – об'єкт фону (камінь, сміття),
помилково класифікований як міна. Висока точність означає мінімум
хибних тривог.
2 Recall (Повнота): Показує частку виявлених мін серед усіх мін, що
реально присутні на зображеннях: , де FN (False
Negative) – пропущена міна.
Важливо: У контексті задачі гуманітарного розмінування метрика
Recall є пріоритетною. Пропуск навіть однієї міни (FN) несе
смертельну загрозу, тоді як хибне спрацювання (FP) призводить лише
до втрати часу сапера на перевірку.
3 mAP@50 (mean Average Precision): Інтегральна метрика, що
усереднює точність по всіх класах при порозі перекриття (IoU -
Intersection over Union) 0.5. Вона дозволяє одним числом оцінити
загальну якість моделі.
84
ЧДТУ 252496.016 ПЗ
4 FPS (Frames Per Second): Частота кадрів. Визначає придатність
системи до роботи в режимі реального часу.
5 Latency (Затримка): Повний час обробки одного кадру, що включає:
− tpre – час попередньої обробки (завантаження, ресайз,
нормалізація).
− tinfer – час проходу нейромережі (Forward pass).
− tpost – час постобробки (NMS, злиття тайлів).
4.2.3.4 Природа хибно позитивних спрацювань (False Positives)
При показнику Precision 0.77, близько 23% детекцій були хибними.
Основними джерелами шуму стали:
− антропогенне сміття: Пластикові пляшки, кришки, уламки шиферу.
Вони мають схожий з пластиковим корпусом ПФМ-1 коефіцієнт
відбиття світла;
− природні об'єкти: Деякі види широкого листя (наприклад, клена)
восени можуть нагадувати форму "пелюстки";
− тіні: Складні візерунки тіней від гілок іноді утворювали форми, схожі
на міни.
4.2.3.5 Природа хибно негативних спрацювань (False Negatives)
Пропуски (16% випадків) здебільшого траплялися за таких умов:
− значне заглиблення: Міна, втоптана в ґрунт або покрита шаром
пилу/бруду більше ніж на 60%. У таких випадках візуальних ознак
недостатньо навіть для людини.
− висока контрастність сцени: При яскравому сонці та глибоких тінях
динамічний діапазон камери не дозволяв розрізнити деталі в тіні, де
знаходилася міна. Режим TTA частково допомагав у таких ситуаціях.
4.2.4 Приймальне тестування
Приймальне тестування не передбачено даним дослідженням.
Таблиця 4.23
85
ЧДТУ 252496.016 ПЗ
Тест-кейс №1 Сценарій «Швидка розвідка ділянки»
Тест-кейс № 1
Оператор завантажує фото місцевості для швидкої перевірки
Опис
наявності загроз
Передумови Оператор отримав серію знімків з розвідувального дрона
1 Завантажити перше фото
Кроки
2 Натиснути «Детектувати» (режим Baseline)
Очікуваний Система за 200 мс вказує на підозрілі зони з великими
результат об'єктами
Фактичний
Оператор отримав миттєву візуальну оцінку сектору
результат
Пройдено Так
Таблиця 4.24
Тест-кейс №2 Сценарій «Детальний аналіз (Deep Scan)»
Тест-кейс № 2
Поглиблена перевірка підозрілої зони з використанням
Опис
тайлінгу для виявлення замаскованих мін
Передумови Виявлено складний ландшафт з високою травою
1 Увімкнути режим «Tiling» та «TTA»
Кроки
2 Запустити аналіз кадру
Очікуваний Система знаходить дрібні фрагменти мін, які були пропущені
результат в швидкому режимі
Фактичний Виявлено додаткові 2 міни, що займали 14 пікселів на
результат оригіналі
Пройдено Так
Таблиця 4.25
Тест-кейс №3 Сценарій «Генерація карти мінної небезпеки»
86
ЧДТУ 252496.016 ПЗ
Тест-кейс № 3
Формування підсумкового документа місії для передачі
Опис
саперним підрозділам
Передумови Обробка папки завершена
1 Натиснути «Експорт результатів»
Кроки
2 Відкрити сформований CSV-файл
Очікуваний Файл містить перелік усіх знайдених ВНП з їх відносними
результат координатами на кадрах
Фактичний Звіт згенеровано, дані готові для імпорту в геоінформаційні
результат системи
Пройдено Так
Таблиця 4.26
Тест-кейс №4: Оцінка зручності інтерфейсу (Usability)
Тест-кейс № 4
Перевірка легкості освоєння програми оператором без
Опис
спеціальної ІТ-освіти
Передумови Новий користувач вперше запускає HELIOS
1 Пройти цикл від запуску до отримання першого результату
Кроки
детекції
Очікуваний Користувач витрачає менше 2 хвилин на запуск першого
результат аналізу завдяки інтуїтивному GUI
Фактичний Структура панелі керування (Секції А, Б, В) визнана
результат логічною та простою
Пройдено Так
4.3 Приклади впровадженого програмного комплексу
Діючий прототип програмного комплексу "HELIOS Professional Mine
Detector" (власна назва).
87
ЧДТУ 252496.016 ПЗ
Працює на ноутбуках середнього класу, знижуючи поріг входу для
волонтерів.
Система звітності JSON/CSV/Geo-tagging сумісна з картами
розмінування.
На наступному рисунку зображено інтерфейс програми, яка запущена та
працює.
Рис. 4.2 – Інтерфейс програми, що розгорнуто та працює
88
ЧДТУ 252496.016 ПЗ
ВИСНОВКИ
У кваліфікаційній роботі вирішено актуальну науково-прикладну задачу
підвищення ефективності дистанційного виявлення малогабаритних
вибухонебезпечних предметів за допомогою безпілотних літальних апаратів.
Результати проведених теоретичних та експериментальних досліджень
дозволяють зробити наступні висновки:
1 Проаналізовано сучасний стан проблеми гуманітарного розмінування
та встановлено, що використання оптичних сенсорів у поєднанні з
методами глибокого навчання є найбільш перспективним підходом для
автоматизації процесу технічної розвідки. Виявлено критичну
проблему "зникнення" дрібних об'єктів (Small Object Detection) при
використанні стандартних методів попередньої обробки зображень
(глобальне масштабування), що призводить до неприпустимо низьких
показників повноти виявлення (Recall < 0.5).
2 Обґрунтовано вибір одностадійної архітектури YOLOv11 як базової
моделі детекції завдяки її Anchor-Free природі та збалансованим
показникам точності й швидкодії. Розроблено теоретичні засади
застосування методів динамічного тайлінгу (Tiling) для збереження
просторової роздільної здатності вхідних даних та Test-Time
Augmentation (TTA) для підвищення стійкості моделі до шумів і
складних умов освітлення.
3 Спроектовано та реалізовано програмний комплекс "HELIOS
Professional Mine Detector", побудований на гібридній архітектурі
MVC. Система підтримує адаптивний вибір стратегії інференсу,
ефективно використовує ресурси Edge-пристроїв (оптимізація пам'яті,
підтримка FP16) та має зручний графічний інтерфейс для оператора.
Реалізовано алгоритм зваженого злиття рамок (Weighted Box Fusion),
який, на відміну від класичного NMS, забезпечує вищу точність
локалізації об'єктів на межах фрагментів зображення.
4 Експериментально доведено, що впровадження розробленого методу
89
ЧДТУ 252496.016 ПЗ
тайлінгу дозволяє підвищити повноту виявлення (Recall) мін типу
ПФМ-1 з 0.42 (для базової моделі) до 0.84. Додаткове застосування
TTA дозволяє досягти показника Recall 0.86. Встановлено, що
швидкодія системи на процесорі загального призначення (AMD Ryzen
4700U) у режимі максимальної точності становить близько 1.8 FPS,
що є достатнім для режиму детального сканування ("зависання") та
пост-аналізу, але вимагає використання спрощених режимів для
навігації в реальному часі.
5 Розроблено рекомендації щодо практичного застосування системи,
які передбачають використання комбінованої тактики: швидкий обліт
території в базовому режимі для виявлення зон інтересу та детальне
сканування в режимі тайлінгу для підтвердження загроз. Така
стратегія дозволяє оптимізувати час виконання місії при збереженні
високого рівня безпеки.
Отримані результати свідчать про те, що розроблена система може
слугувати ефективним інструментом для допомоги саперам та операторам
БПЛА у виявленні поверхневих мінних забруднень, знижуючи ризики для
життя персоналу та прискорюючи процес розмінування.
90
ЧДТУ 252496.016 ПЗ
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1 Закон України «Про протимінну діяльність в Україні» від 06.12.2018
№ 2642-VIII. Відомості Верховної Ради України. 2019. № 2. Ст. 10.
2 Національний стандарт України ДСТУ-П 8820:2018 «Протимінна
діяльність. Процеси управління. Основні положення». Київ: ДП
«УкрНДНЦ», 2019. 32 с.
3 Ткачук А., Кузьменко І. Аналіз методів виявлення вибухонебезпечних
предметів за допомогою безпілотних літальних апаратів. Системи
управління, навігації та зв’язку. 2022. Вип. 1 (67). С. 112–117.
4 Akyon F. C., Altinuc S. O., Temizel A. Slicing Aided Hyper Inference and
Fine-tuning for Small Object Detection. 2022 IEEE International
Conference on Image Processing (ICIP). Bordeaux, France, 2022. P. 966–
970. doi: 10.1109/ICIP46576.2022.9897990.
5 Bochkovskiy A., Wang C.-Y., Liao H.-Y. M. YOLOv4: Optimal Speed and
Accuracy of Object Detection. arXiv preprint arXiv:2004.10934. 2020.
URL: https://arxiv.org/abs/2004.10934.
6 Bradski G. The OpenCV Library. Dr. Dobb's Journal of Software Tools.
2000. Vol. 25. P. 120–125. URL: https://www.google.com/search?q=
http://www.drdobbs.com/open-source/the-opencv-library/184404319.
7 Gevorgyan Z. SIoU Loss: More Powerful Learning for Bounding Box
Regression. arXiv preprint arXiv:2205.12740. 2022. URL:
https://arxiv.org/abs/2205.12740.
8 Jocher G., Chaurasia A., Qiu J. Ultralytics YOLOv8. GitHub repository.
2023. URL: https://github.com/ultralytics/ultralytics.
9 Lin T.-Y., Goyal P., Girshick R., He K., Dollár P. Focal Loss for Dense
Object Detection. Proceedings of the IEEE international conference on
computer vision. 2017. P. 2980–2988.
10 Liu S., Qi L., Qin H., Shi J., Jia J. Path Aggregation Network for Instance
Segmentation. Proceedings of the IEEE Conference on Computer Vision
and Pattern Recognition (CVPR). 2018. P. 8759–8768.
91
ЧДТУ 252496.016 ПЗ
11 Paszke A., Gross S., Massa F., Lerer A., Bradbury J., Chanan G. PyTorch:
An Imperative Style, High-Performance Deep Learning Library. Advances
in Neural Information Processing Systems. 2019. Vol. 32. P. 8024–8035.
URL: https://pytorch.org/.
12 Redmon J., Divvala S., Girshick R., Farhadi A. You Only Look Once:
Unified, Real-Time Object Detection. Proceedings of the IEEE conference
on computer vision and pattern recognition. 2016. P. 779–788.
13 Rezatofighi H., Tsoi N., Gwak J., Sadeghian A., Reid I., Savarese S.
Generalized Intersection over Union: A Metric and A Loss for Bounding
Box Regression. Proceedings of the IEEE/CVF Conference on Computer
Vision and Pattern Recognition. 2019. P. 658–666.
14 Solovyev R., Wang W., Gabruseva T. Weighted Box Fusion: Ensembling
Boxes for Object Detection Models. Image and Vision Computing. 2021.
Vol. 106. 104117. doi: 10.1016/j.imavis.2021.104117.
15 Terven J., Cordova-Esparza D. A Comprehensive Review of YOLO
Architectures in Computer Vision: From YOLOv1 to YOLOv8 and YOLO-
NAS. Machine Learning and Knowledge Extraction. 2023. Vol. 5. No. 4. P.
1680–1716. doi: 10.3390/make5040083.
16 Wang C.-Y., Bochkovskiy A., Liao H.-Y. M. YOLOv7: Trainable bag-of-
freebies sets new state-of-the-art for real-time object detectors. Proceedings
of the IEEE/CVF Conference on Computer Vision and Pattern Recognition.
2023. P. 7464–7475.
17 Wang Z., Wu Y. Ensembling with Test-Time Augmentation for Object
Detection. 2021 IEEE International Conference on Multimedia and Expo
Workshops (ICMEW). Shenzhen, China, 2021. P. 1–6.
18 Documentation for Ultralytics YOLOv11. Ultralytics Docs. URL:
https://docs.ultralytics.com.
19 PFM-1 'Petal' Anti-personnel Mine. CAT-UXO (Collaborative ordance data
repository). URL: https://cat-uxo.com/explosive-hazards/landmines/pfm-1-
landmine.
92
ЧДТУ 252496.016 ПЗ
20 Tkinter – Python interface to Tcl/Tk. Python 3.12.3 Documentation. URL:
https://docs.python.org/3/library/tkinter.html.
93
ДОДАТОК А
ЗАТВЕРДЖЕНО:
Зав. каведри ПЗАС
проф. Голуб С. В.
__________________________
СТРУКТУРНА ІДЕНТИФІКАЦІЯ ІНФОРМАЦІЙНИХ СИСТЕМ
РОЗПІЗНАВАННЯ МАЛОГАБАРИТНИХ ОБ'ЄКТІВ
Специфікація
482 ЧДТУ 252496.016
Листів 2
Розробник ________________ Строганов Я.Р.
Керівник ________________ Метелап В.В
Черкаси 2025
482 ЧДТУ 252496.016 2
Позначення Найменування Примітка
482.ЧДТУ 252496 12-01 Лістинг програми
482.ЧДТУ 252496 90-01 Графічні матеріали
95
ДОДАТОК Б
СТРУКТУРНА ІДЕНТИФІКАЦІЯ ІНФОРМАЦІЙНИХ СИСТЕМ
РОЗПІЗНАВАННЯ МАЛОГАБАРИТНИХ ОБ'ЄКТІВ
Лістинг програм
482 ЧДТУ 252496 12 01
Листів 7
Розробник ________________ Строганов Я.Р.
2025
2
ЗМІСТ
Лістинг Б.1 – Конфігурація середовища та імпорт бібліотек ....................................... 3
Лістинг Б.2 – Інтерфейс класу детектора HeliosMineDetector ...................................... 3
Лістинг Б.3 – Головна функція та обробка аргументів ................................................. 4
Лістинг Б.4 – Графічний інтерфейс: структура класу HeliosGUI ................................. 5
Лістинг Б.5 – Методи обробки подій інтерфейсу .......................................................... 6
Лістинг Б.6 – Точка входу в графічний застосунок ....................................................... 7
482 ЧДТУ 252496 12 01 3
Лістинг Б.1 – Конфігурація середовища та імпорт бібліотек
import os
import sys
import cv2
import numpy as np
import argparse
import logging
from pathlib import Path
from datetime import datetime
from typing import List, Tuple, Dict, Optional, Union
import json
import uuid
# Імпорт бібліотек машинного навчання з обробкою помилок
try:
from ultralytics import YOLO
import torch
except ImportError as e:
# ... (код обробки помилок імпорту скорочено)
sys.exit(1)
# Глобальні константи конфігурації
DEFAULT_CONFIDENCE = 0.25
DEFAULT_IOU = 0.45
LOG_FORMAT = '%(asctime)s - %(name)s - %(levelname)s -
%(message)s'
Лістинг Б.2 – Інтерфейс класу детектора HeliosMineDetector
class HeliosMineDetector:
"""
Клас-обгортка для моделі YOLO, що реалізує логіку детекції,
ансамблювання моделей та обробки результатів.
"""
def __init__(self, model_path: Union[str, List[str]] = None,
confidence: float = 0.25,
ensemble: bool = False, logs_dir: str = 'logs',
results_dir: str = 'results',
ensemble_mode: str = 'nms', device:
Optional[str] = None,
tiling: bool = False, tile_size: int = 1024):
"""
Ініціалізація детектора.
Args:
model_path: Шлях до файлу моделі (.pt) або список
шляхів.
confidence: Поріг впевненості детекції.
98
482 ЧДТУ 252496 12 01 4
ensemble: Прапор використання ансамблю моделей.
device: Пристрій для обчислень ('cpu' або 'cuda').
tiling: Використання технології SAHI (tiling) для
великих зображень.
"""
self.session_id = f"{datetime.now().strftime('%Y%m%d')}-
{uuid.uuid4().hex[:8]}"
self.logs_dir = Path(logs_dir)
self.results_dir = Path(results_dir)
# ... (ініціалізація змінних класу та логера) ...
if model_path:
# ... (логіка вибору методу завантаження моделей) ...
pass
def load_model(self, path: str) -> YOLO:
"""Завантаження одиночної моделі YOLO."""
# ... (реалізація завантаження та перенесення на GPU) ...
return model
def detect_image(self, image_source: Union[str, np.ndarray],
save_result: bool = True):
"""
Виконує детекцію на одному зображенні.
"""
# ... (препроцесинг зображення) ...
# ... (інференс моделі) ...
# ... (постпроцесинг та збереження результатів) ...
pass
def detect_folder(self, folder_path: str, batch_size: int =
None):
"""Пакетна обробка папки із зображеннями."""
# ... (ітерація по файлах та виклик detect_image) ...
pass
Лістинг Б.3 – Головна функція та обробка аргументів
def parse_arguments():
"""Налаштування парсера аргументів командного рядка."""
parser = argparse.ArgumentParser(description="H.E.L.I.O.S
Mine Detector")
parser.add_argument("--image", type=str, help="Path to single
image")
parser.add_argument("--folder", type=str, help="Path to
folder")
parser.add_argument("--model", type=str,
99
482 ЧДТУ 252496 12 01 5
default="models/best.pt")
# ... (інші аргументи CLI) ...
return parser.parse_args()
if __name__ == "__main__":
args = parse_arguments()
try:
# Ініціалізація головного об'єкта
detector = HeliosMineDetector(
model_path=args.model,
confidence=args.confidence,
# ... (передача параметрів) ...
)
# Вибір режиму роботи на основі аргументів
if args.image:
detector.detect_image(args.image)
elif args.folder:
detector.detect_folder(args.folder)
# ... (інші режими) ...
except KeyboardInterrupt:
print("\n� Зупинено користувачем")
except Exception as e:
# ... (логірування критичних помилок) ...
sys.exit(1)
Лістинг Б.4 – Графічний інтерфейс: структура класу HeliosGUI
"""
H.E.L.I.O.S GUI Mine Detector
Модуль графічного інтерфейсу користувача на базі бібліотеки
Tkinter.
"""
import tkinter as tk
from tkinter import ttk, filedialog
import threading
# ... (імпорт інших бібліотек GUI) ...
class HeliosGUI:
"""Головний клас графічного інтерфейсу."""
def __init__(self, root):
self.root = root
self.root.title("H.E.L.I.O.S Mine Detector -
Professional")
100
482 ЧДТУ 252496 12 01 6
self.root.geometry("1200x800")
self.detector = None
self.current_image_path = None
self.detection_results = []
# Налаштування стилів та віджетів
self.setup_styles()
self.create_widgets()
# Запуск ініціалізації детектора у фоновому потоці
self.initialize_detector()
def setup_styles(self):
"""Визначення кольорової схеми та стилів віджетів."""
style = ttk.Style()
style.theme_use('clam')
# ... (налаштування кольорів теми) ...
def create_widgets(self):
"""Створення компонування інтерфейсу."""
# Створення головного контейнера
main_container = ttk.Frame(self.root)
main_container.pack(fill=tk.BOTH, expand=True)
# ... (створення панелі керування, області перегляду та
логу) ...
pass
Лістинг Б.5 – Методи обробки подій інтерфейсу
def load_image_dialog(self):
"""Відкриття діалогового вікна вибору файлу."""
file_path = filedialog.askopenfilename(
filetypes=[("Images", "*.jpg *.jpeg *.png *.bmp")]
)
if file_path:
self.current_image_path = file_path
self.display_original_image(file_path)
def start_detection(self):
"""Запуск процесу детекції у окремому потоці."""
if not self.detector:
return
# ... (перевірка вхідних даних) ...
# Запуск потоку обробки
threading.Thread(target=self._run_detection_process,
daemon=True).start()
101
482 ЧДТУ 252496 12 01 7
def _run_detection_process(self):
"""Внутрішній метод виконання детекції."""
# ... (виклик методу детектора та оновлення UI
результатами) ...
pass
def on_result_select(self, event=None):
"""Обробка вибору рядка в таблиці результатів."""
# ... (відображення вибраного результату) ...
pass
def update_log(self, message):
"""Потокобезпечне оновлення текстового поля логу."""
# ... (реалізація виводу повідомлень) ...
pass
Лістинг Б.6 – Точка входу в графічний застосунок
def main():
"""Ініціалізація та запуск головного циклу подій."""
root = tk.Tk()
# Налаштування іконки та параметрів вікна
# ...
app = HeliosGUI(root)
root.mainloop()
if __name__ == "__main__":
main()
102
ДОДАТОК B
СТРУКТУРНА ІДЕНТИФІКАЦІЯ ІНФОРМАЦІЙНИХ СИСТЕМ
РОЗПІЗНАВАННЯ МАЛОГАБАРИТНИХ ОБ'ЄКТІВ
Графічні матеріали
482 ЧДТУ 252496 90 01
Листів ____
Розробник ________________ Строганов Я.Р.
2025
2
ЗМІСТ
Рис. В.1 - Повна діаграма класів ................................................................................. 3
Рис. В.2 - Діаграма компонентів ................................................................................. 4
Рис. В.3 - Функціональна схема програмного комплексу ........................................ 4
Рис. В.4 - Діаграма діяльності ...................................................................................... 5
Рис. В.5 - Діаграма скінченого автомату ................................................................... 6
Рис. В.6– Титульний слайд презентації ...................................................................... 7
Рис. В.7 – Перелік умовних позначень ....................................................................... 7
Рис. В.8 – Актуальність проблеми ............................................................................... 8
Рис. В.9 – Проблема виявлення малих об’єктів ......................................................... 8
Рис. В.10 – Мета та завдання........................................................................................ 9
Рис. В.11 – Аналіз сенсорів .......................................................................................... 9
Рис. В.12 – Вибір архітектури ...................................................................................... 10
Рис. В.13 – Зникнення ознак ........................................................................................ 10
Рис. В.14 – Тайлінг ........................................................................................................ 11
Рис. В.15 – ТТА ............................................................................................................. 11
Рис. В.16 – Постобробка ............................................................................................... 12
Рис. В.17 – Архітектура ................................................................................................ 12
Рис. В.18 – Алгоритм .................................................................................................... 13
Рис. В.19 – Умови експерименту ................................................................................. 13
Рис. В.20 – Результати точності ................................................................................... 14
Рис. В.21 – Результати швидкодії ................................................................................ 14
Рис. В.22 – Аналіз помилок .......................................................................................... 15
Рис. В.23 – Наукова новизна ........................................................................................ 15
Рис. В.24 – Практичне значення .................................................................................. 16
Рис. В.25 – Юз Кейс діаграма ...................................................................................... 16
Рис. В.26 – Діаграма класів .......................................................................................... 17
Рис. В.27 – Діаграма діяльності ................................................................................... 17
Рис. В.28 – Діаграма послідовності ............................................................................. 18
Рис. В.29 – Діаграма компонентів ............................................................................... 18
Рис. В.30 – Діаграма розгортання ................................................................................ 19
Рис. В.31 - Слайди презентації кваліфікаційної роботи ............................................ 19
482 ЧДТУ 252496 90 01 3
Рис.В.1 – Повна діаграма класів
105
482 ЧДТУ 252496 90 01 4
Рис.В.2 – Діаграма компонентів
Рис.В.3 - Функціональна схема програмного комплексу
106
482 ЧДТУ 252496 90 01 5
Рис.В.4 – Діаграма діяльності
107
482 ЧДТУ 252496 90 01 6
Рис.В.5 – Діаграма скінченого автомату
108
482 ЧДТУ 252496 90 01 7
Рис. В.6 – Титульний слайд презентації
Рис. В.7 – Перелік умовних позначень
109
482 ЧДТУ 252496 90 01 8
4
Рис. В.8 – Актуальність проблеми
Рис. В.9 – Проблема виявлення малих об’єктів
110
482 ЧДТУ 252496 90 01 9
Рис. В.10 – Мета та завдання
Рис. В.11 – Аналіз сенсорів
111
482 ЧДТУ 252496 90 01 10
Рис. В.12 – Вибір архітектури
Рис. В.13 – Зникнення ознак
112
482 ЧДТУ 252496 90 01 11
Рис. В.14 – Тайлінг
Рис. В.15 – ТТА
113
482 ЧДТУ 252496 90 01 12
Рис. В.16 – Постобробка
Рис. В.17 – Архітектура
114
482 ЧДТУ 252496 90 01 13
Рис. В.18 – Алгоритм
Рис. В.19 – Умови експерименту
115
482 ЧДТУ 252496 90 01 14
Рис. В.20 – Результати точності
Рис. В.21 – Результати швидкодії
116
482 ЧДТУ 252496 90 01 15
Рис. В.22 – Аналіз помилок
Рис. В.23 – Наукова новизна
117
482 ЧДТУ 252496 90 01 16
Рис. В.24 – Практичне значення
Рис. В.25 – Юз Кейс діаграма
118
482 ЧДТУ 252496 90 01 17
Рис. В.26 – Діаграма класів
Рис. В.27 – Діаграма діяльності
119
482 ЧДТУ 252496 90 01 18
Рис. В.28 – Діаграма послідовності
Рис. В.29 – Діаграма компонентів
120
482 ЧДТУ 252496 90 01 19
Рис. В.30 – Діаграма розгортання
Рис. В.31 – Закриваючий слайд
121