Дослідження систем автоматизованого доступу і обліку автомобілів на автостоянці.

Месеча, Сергій Андрійович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6436
Title:	Дослідження систем автоматизованого доступу і обліку автомобілів на автостоянці.
Authors:	Зубко, Ігор Анатолійович Месеча, Сергій Андрійович
Issue Date:	Jan-2026
Abstract:	У ході виконання кваліфікаційного проєкту було розроблено, досліджено та експериментально підтверджено працездатність автоматизованої системи контролю доступу на автостоянку на основі технології розпізнавання номерних знаків (ANPR). У роботі проведено повний цикл створення програмно-апаратного комплексу — від аналізу існуючих рішень і формування вимог до побудови архітектури, розробки програмного забезпечення, проведення експериментів і економічного обґрунтування впровадження. Отримані результати свідчать про те, що запропонована система може бути використана як у комерційних, так і в промислових умовах.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6436
Appears in Collections:	174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)
Files in This Item:
File	Description	Size	Format
М_174_2025_Месеча.pdf Restricted Access		838.79 kB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ 
 
 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
освітнього ступеню «магістр» 
 
 
на тему: ДОСЛІДЖЕННЯ СИСТЕМ АВТОМАТИЗОВАНОГО 
ДОСТУПУ І ОБЛІКУ АВТОМОБІЛІВ НА АВТОСТОЯНЦІ. 
 
 
 
Виконав: здобувач вищої освіти 2 курсу,  
групи МАКІТ-2409 
спеціальності 174 Автоматизація, 
комп’ютерно-інтегровані технології та 
робототехніка (освітня програма 
«Автоматизація та комп’ютерно-
інтегровані системи та компоненти») 
           Сергій МЕСЕЧА     
(ім’я та ПРІЗВИЩЕ) 
 
Керівник                   Ігор ЗУБКО    
            (ім’я та ПРІЗВИЩЕ)   
 
Рецензент         
(ім’я та ПРІЗВИЩЕ)
                          
 
 
 
Черкаси 2025 року 
ЗМІСТ 
СПИСОК СКОРОЧЕНЬ ТА АБРЕВІАТУР………………………………………4 
ВСТУП……………………………………………………………………………..7 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ……………...…………………….8 
РОЗДІЛ 1. ОГЛЯД І АНАЛІЗ ІСНУЮЧИХ СИСТЕМ АВТОМАТИЗОВАНОГО 
ДОСТУПУ І ОБЛІКУ АВТОМОБІЛІВ НА АВТОСТОЯНЦІ………………….10 
1.1. Сучасні тенденції розвитку систем автоматизованого доступу на 
автостоянках……………………………………………………………………...10 
1.2. Класифікація систем контролю доступу…………………………………...12 
1.3. Технологія ANRP(Automatic Number Plate Recognition) та алгоритм 
розпізнавання номерних знаків…………………………………………………15 
1.4. Аналіз сучасних систем контролю доступу та комерційних ANPR-
рішень…………………………………………………………………………….24 
1.5. Висновок до розділу 1……………………………………………………….29 
РОЗДІЛ 2. ПРОЄКТУВАННЯ СИСТЕМИ АВТОМАТИЗОВАНОГО 
ДОСТУПУ І ОБЛІКУ АВТОМОБІЛІВ НА АВТОСТОЯНЦІ………………….31 
2.1. Постановка задачі…………………………………………………………...31 
2.2. Функціональні вимоги до системи…………………………………………32 
2.3. Нефункціональні вимоги та обмеження системи………………………….34 
2.4. Обґрунтування вибору обладнання………………………………………..36 
2.5. Архітектура системи………………………………………………………..39 
2.6. Проєктування бази даних…………………………………………………...49 
2.7. Алгоритм роботи системи…………………………………………………..54 
2.8. Висновки до розділу 2………………………………………………………59 
РОЗДІЛ 3. РОЗРОБЛЕННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ТА 
АЛГОРИТМУ РОЗПІЗНАННЯ НОМЕРНИХ ЗНАКІВ……………………….63 
3.1. Загальна структура програмного забезпечення…………………………...63 
3.2. Технологічний стек………………………………………………………….65 
3.3. Алгоритм детекції та виділення номерного знаку (YOLO)………………68 
2 
 
3.4. Передобробка зображення перед OCR…………………………………….71 
3.5. Розпізнавання символів номерного знаку (OCR)…………………………73 
3.6. Взаємодія з базою даних (API)……………………………………………..75 
3.7. Інтерфейс оператора (веб-частина)………………………………………...78 
 3.8. Висновки до розділу 3……………………………………………………...82 
РОЗДІЛ 4. Моделювання, експериментальні дослідження та тестування 
системи…………………………………………………………………………...85 
4.1. Мета моделювання……………………………………………………….....85 
 4.2. Вихідні дані для моделювання…………………………………………….86 
4.3. Методика проведення експерименту……………………………………....89 
4.4. Результати тестування детектора номерних знаків (YOLOv5)…………..91 
4.5. Результати тестування OCR-модулю………………………………………94 
 4.6. Тестування системи в сценаріях експлуатації…………………………....95 
4.7. Вплив факторів зовнішнього середовища на точність…………………...96 
4.8. Висновки до розділу 4………………………………………………………96 
РОЗДІЛ 5. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ПРОЄКТУ.………………….99 
5.1. Економічна доцільність впровадження системи……………………….....99 
5.2. Кошторис впровадження системи……………………………………….....99 
5.3. Економічний ефект……………………………………………………...…100 
5.4. Аналіз ризиків та заходи мінімізації………………………………….…..101 
5.5. Висновки до розділу 5……………………………………………………..102 
ВИСНОВКИ…………………………………………………………………….104 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ………………………………………107 
 
 
 
 
 
3 
 
СПИСОК СКОРОЧЕНЬ ТА АБРЕВІАТУР 
1. Загальнотехнічні скорочення 
ANPR — Automatic Number Plate Recognition (автоматичне розпізнавання 
номерних знаків) 
LPR — License Plate Recognition (розпізнавання номерних знаків) 
FPS — Frames Per Second (кількість кадрів за секунду) 
ROI — Region of Interest (область інтересу на зображенні) 
GT — Ground Truth (еталонні дані) 
API — Application Programming Interface (програмний інтерфейс застосунку) 
UI — User Interface (інтерфейс користувача) 
UX — User Experience (досвід користувача) 
MVC / MVVM — архітектурні патерни програмування 
2. Комп’ютерний зір та штучний інтелект 
YOLO — You Only Look Once (модель детекції об’єктів) 
CNN — Convolutional Neural Network (згорткова нейронна мережа) 
DNN — Deep Neural Network (глибока нейронна мережа) 
CRNN — Convolutional Recurrent Neural Network (згорткова рекурентна 
мережа) 
NMS — Non-Maximum Suppression (пригнічення немаксимальних значень) 
OCR — Optical Character Recognition (оптичне розпізнавання символів) 
CLAHE — Contrast Limited Adaptive Histogram Equalization 
TP — True Positive (правильне спрацювання) 
FP — False Positive (помилкове спрацювання) 
FN — False Negative (пропущене спрацювання) 
Precision — точність детектора 
Recall — повнота детектора 
F1-score — узагальнена метрика якості детекції 
3. Обробка зображень 
HSV / RGB / BGR — колірні моделі 
SSIM — Structural Similarity Index (структурний індекс подібності) 
PSNR — Peak Signal-to-Noise Ratio 
Otsu — алгоритм бінаризації методом Оцу 
Deskew — алгоритм вирівнювання нахилу 
Sharpen — фільтр покращення різкості 
4. Програмування та серверні технології 
4 
 
JSON — JavaScript Object Notation 
REST — Representational State Transfer 
HTTP / HTTPS — протокол передавання гіпертексту 
JWT — JSON Web Token (токен автентифікації) 
ORM — Object Relational Mapping 
SQL — Structured Query Language 
DB — Database (база даних) 
CRUD — Create, Read, Update, Delete (базові операції БД) 
WS — WebSocket 
CORS — Cross-Origin Resource Sharing 
SSL / TLS — протоколи шифрування даних 
CSS / HTML / JS — мови веб-розробки 
SPA — Single Page Application 
DNS — Domain Name System 
5. Мережеві технології 
RTSP — Real-Time Streaming Protocol 
TCP / UDP — транспортні протоколи Інтернету 
IP — Internet Protocol 
PoE — Power over Ethernet (живлення по Ethernet) 
LAN / WAN — локальна / глобальна мережа 
6. Електроніка, обладнання та автоматика 
IR — Infrared (інфрачервоне світло) 
UPS — Uninterruptible Power Supply (безперебійне живлення) 
DC — Direct Current (постійна напруга) 
AC — Alternating Current (змінна напруга) 
GPIO — General Purpose Input/Output 
PCB — Printed Circuit Board (друкована плата) 
PCB Trace — провідники плати 
Dry Contact — “сухий контакт”, безнапругове реле 
RSSI — Received Signal Strength Indicator 
7. Інформаційна безпека 
RBAC — Role-Based Access Control (керування доступом на основі ролей) 
ACL — Access Control List (список контролю доступу) 
PII — Personally Identifiable Information (персональні дані) 
CSP — Content Security Policy 
5 
 
2FA — Two-Factor Authentication (двофакторна автентифікація) 
IDS / IPS — системи виявлення / попередження вторгнень 
8. Економіка та управління проєктами 
ROI (Return on Investment) — рентабельність інвестицій 
OPEX — Operating Expenditures (операційні витрати) 
CAPEX — Capital Expenditures (капітальні витрати) 
TCO — Total Cost of Ownership (повна вартість володіння) 
9. Стандарти та нормативи 
ISO — International Organization for Standardization 
IEC — International Electrotechnical Commission 
ДСТУ — Державний стандарт України 
ПУЕ — Правила улаштування електроустановок 
НАПБ — Норми пожежної безпеки 
  
6 
 
ВСТУП 
 У сучасних містах автомобільний транспорт є основним засобом 
пересування. За статистикою до 30 відсотків трафіку в місті створюється 
водіями, що шукають вільне місце для паркування. Це призводить до 
сповільнення трафіку, створення додаткових заторів, що в свою чергу викликає 
додаткові викиди СО2 в атмосферу. Постійне збільшення кількості 
автомобільного транспорту в містах створює необхідність ефективного 
управління зонами для паркування. 
 Існує багато методів контролю доступу до паркувальних майданчиків. Ці 
методи є морально застарілими, а також залежними від людини. В цих 
системах людина є основною причиною сповільнення процесу. Прийняття 
рішення охороною, пошук пропуску, чи карти, отримання талону – такі дії на 
сучасних паркувальних майданчиках створюють додаткові затримки на 
в’їздах, що в свою чергу призводить до зупинок руху на прилеглих до паркінгів 
смугах руху. 
 Із розвитком сучасних технологій та штучного інтелекту з’явилась 
можливість автоматизації контролю доступу шляхом розпізнавання номерних 
знаків. При використанні ANRP ідентифікатором доступу є безпосередньо 
автомобіль. Цей метод не потребує пропусків, чи талонів, а також дозволяє 
уникнути затримок спричинених людським фактором. 
 Завдяки застосуванню алгоритмів розпізнавання тексту, сучасні системи 
здатні розпізнавати номерні знаки з високою точністю. Такі алгоритми можуть 
розпізнавати номерні знаки в реальному часі навіть в поганих умовах та під 
великими кутами огляду камери. 
 Використання ANRP також дає змогу уникнути ризиків пов’язаних з 
людиною, скоротити витрати на персонал, збільшити швидкість проходження 
авторизації, а також забезпечити повний цифровий облік подій. Ці переваги 
визначають актуальність впровадження систем розпізнавання номерних знаків 
на комерційних та закритих паркувальних майданчиках. 
7 
 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ 
 Об’єктом дослідження є процес контролю доступу та обліку 
транспортних засобів на паркувальних майданчиках, що включає взаємодію 
технічних, програмних та організаційних засобів для забезпечення 
ідентифікації автомобілів, автоматизації пропускних операцій, підвищення 
безпеки та оптимізації роботи паркувальної інфраструктури. 
 У межах роботи об’єкт розглядається як комплексна система, що 
охоплює: потокове відеоспостереження за транспортними засобами, 
процедури їх ідентифікації, контроль відкриття/закриття шлагбаума, фіксацію 
та збереження інформації про в’їзди/виїзди, використання апаратних засобів, 
взаємодію оператора або адміністратора з системою. 
 Предметом дослідження є методи автоматизованого розпізнавання 
номерних знаків транспортних засобів та способи їх інтеграції в 
автоматизовану інформаційно-керуючу систему контролю доступу. 
 У межах предмета дослідження розглядаються: алгоритми детекції 
номерних знаків на відеопотоці, методи передобробки зображень, алгоритми 
OCR, моделі прийняття рішень Allow/Deny на основі бази дозволених 
автомобілів, механізми взаємодії з апаратними реле та шлагбаумом, REST API 
як інтерфейс між модулями системи, архітектурні рішення та моделі даних для 
забезпечення надійної та швидкої роботи. 
 Метою роботи є розробити, реалізувати та експериментально дослідити 
модель автоматизованої системи контролю доступу на паркувальний 
майданчик, що базується на технології комп’ютерного зору та автоматичного 
розпізнавання номерних знаків (ANPR). 
 Досягнення поставленої мети передбачає створення повного програмно-
апаратного прототипу, який включає: автономний модуль детекції та 
розпізнавання номерних знаків, систему прийняття рішень і керування 
шлагбаумом, інформаційну базу подій та транспортних засобів, 
8 
 
користувацький веб-інтерфейс оператора, моделі взаємодії між компонентами 
в реальному часі, експериментальну валідацію точності та швидкодії. 
Завдання дослідження: 
1. Проаналізувати існуючі системи контролю доступу. 
2. Визначити вимоги до апаратних засобів і програмного забезпечення. 
3. Розробити архітектуру системи та модель бази даних. 
4. Розробити алгоритм розпізнавання номерів. 
5. Провести експериментальні дослідження точності та продуктивності 
системи. 
6. Виконати економічне обґрунтування. 
 Наукова новизна роботи полягає у поєднанні сучасних методів детекції 
номерних знаків з удосконаленим процесом передобробки та постобробки 
OCR, що забезпечило значне підвищення точності розпізнавання в реальних 
умовах зйомки. Запропоноване рішення включає модульну архітектуру із 
забезпеченням локальної обробки даних, що підвищує відмовостійкість та 
швидкодію системи, а також розроблений механізм багатокадрового 
голосування, який зменшує кількість помилкових розпізнавань.  
 Практична цінність роботи полягає у створенні повноцінного 
програмного прототипу системи ANPR, який може бути безпосередньо 
інтегрований у реальну інфраструктуру паркувальних майданчиків та 
контрольних пунктів доступу. Розроблена система здатна працювати в режимі 
реального часу, підтримує масштабування на декілька камер і КПП, забезпечує 
журналювання, аналітику та безпечний доступ через веб-інтерфейс. 
Запропонована технологія дозволяє суттєво знизити операційні витрати, 
підвищити пропускну здатність і рівень безпеки об’єкта, що робить її 
економічно доцільною та технологічно актуальною для широкого 
використання. 
 Апробація результатів: Студентська науково-практична конференція 
2025 
9 
 
РОЗДІЛ 1. ОГЛЯД І АНАЛІЗ ІСНУЮЧИХ СИСТЕМ 
АВТОМАТИЗОВАНОГО ДОСТУПУ І ОБЛІКУ АВТОМОБІЛІВ НА 
АВТОСТОЯНЦІ 
 1.1. Сучасні тенденції розвитку систем автоматизованого доступу на 
автостоянках 
 У сучасних містах автомобільний транспорт є основним засобом 
пересування. За статистикою до 30 відсотків трафіку в місті створюється 
водіями, що шукають вільне місце для паркування. Це призводить до 
сповільнення трафіку, створення додаткових заторів, що в свою чергу викликає 
додаткові викиди СО2 в атмосферу. Відповідно, потреба в автоматизації є не 
лише логістичним, але й екологічним та економічним викликом. 
 Перші системи паркування були повністю ручними: автомобілі 
пропускались охоронцем, який записував номер авто в журнал. Такий підхід 
був виправданий малим навантаженням подібних об’єктів, однак зі 
збільшенням транспортних засобів він виявився неефективним через низьку 
пропускну здатність та високу залежність від людського фактору.  
 Поступовий розвиток автоматизації проходить в кілька етапів: 
1. Ручний контроль: охоронець перевіряє авто і вручну керує шлагбаумом. 
2. Механізовані талонні системи: на в’їзді водій отримує друкований талон. 
3. RFID-системи: замість талона водій використовує електронну картку як 
пропуск. 
4. Система комп’ютерного зору: ідентифікація здійснюється через 
розпізнавання державних номерних знаків. 
5. Smart Parking: інтегровані комплекси з аналітикою 
 У сучасних містах спостерігається перехід до 3-5 етапу, де пропуск 
автомобіля здійснюється не людиною чи карткою, а алгоритмом штучного 
інтелекту. 
 Основними чинниками, що призвели до заміни старих систем на 
автоматизовані є: 
10 
 
• Зростання кількості автомобілів, особливо в містах-мільйонниках; 
• Вимога швидкості обслуговування – користувач не хоче чекати біля 
шлагбаума; 
• Економічна невигідність утримання персоналу; 
• Цифровізація бізнес-процесів і міст( Smart City). 
 Сучасні об’єкти (БЦ, ТРЦ, ЖК) прагнуть забезпечити мінімальний 
рівень контакту людини з системою. Особливо це стало актуальним після 
пандемії COVID-19, коли явище безконтактного доступу стало стандартом. 
 У RFID та талонних системах використовувався фізичний носій 
пропуску: Талон – паперовий документ з кодом; RFID-картка або брелок – 
ідентифікаційний засіб. 
 Недолік таких систем – можливість передачі пропуску іншій людині. Це 
створює ризики для приватних стоянок. Де сторонні особи без доступу можуть 
нелегально проникати на об’єкт. 
 Системи ANRP змінюють концепцію доступу: пропуском стає сам 
автомобіль. Алгоритм розпізнає номерні знаки автомобіля, перевіряє його в 
базі і приймає рішення про відкриття шлагбаума, або фіксує час заїзду та номер 
авто. Користувач не взаємодіє з системою, не дістає картку , чи талон – процес 
відбувається автоматично й безконтактно. 
 Подальшим розвиток ANRP стала інтеграція з комплексами Smart 
Parking, де: 
• Камери розпізнають номер авто на в’їзді; 
• Система визначає вільні місця; 
• Оплата здійснюється автоматично, через додаток; 
• Дані передаються до хмарної інфраструктури. 
 Подібні системи реалізовані у: 
• Варшаві(інтелектуальні муніципальні паркінги) 
• Барселоні(розумне місто, інтегроване з навігцаєю) 
11 
 
• Києві(пілотні паркінги ТРЦ та ЖК) 
 У деяких країнах ANRP використовується для автоматичного 
виписування штрафів за порушення правил дорожнього руху. 
 Оскільки ANRP-система працює без персоналу і фізичних носіїв даних: 
• Відбувається економія коштів на постійному черговому/охоронцю,  
• Зникають витрати на RFID-картки, принтери та папір для талонів, 
• Підвищується прозорість обліку і виключається корупційний чинник. 
 Таким чином, ANRP має не лише технічні, а й економічні переваги, що 
призводить до швидкої окупності впровадженої системи. 
 Впровадження автоматизованих систем контролю доступу є 
закономірним етапом розвитку інфраструктури автостоянок. Тенденції 
світового ринку свідчать, що ручні методи вже не справляються з потоком 
транспорту, талонні й RFID-системи поступаються через необхідність 
фізичних носіїв. Саме ANRP стає стандартом завдяки швидкому 
автоматичному і безконтактному доступі. 
 Отже розпізнавання номерних знаків з технологією штучного інтелекту 
є сучасним, перспективним та економічно доцільним рішенням для 
автоматизації паркувальних майданчиків. 
1.2 . Класифікація систем контролю доступу 
 Управління доступом до автостоянок – це процес, що забезпечує 
ідентифікацію транспортного засобу та прийняття рішення про в’їзд/виїзд. 
Вибір методики контролю визначає: рівень автоматизації, швидкість пропуску 
автомобілів, можливість інтеграції з обліковими чи платіжними системами. 
 Існує чотири групи систем контролю доступу: 
• Ручні 
• Талонні 
• RFID 
12 
 
• ANRP 
Таблиця 1.  
Порівняння систем за принципом ідентифікації 
Тип Метод Дії водія Швидкість Рівень 
системи ідентифікації пропуску(в автоматизації 
ідеальних 
умовах) 
Ручна Охоронець візуально Зупинка, 20-40 секунд Низький 
перевіряє авто спілкування з 
охоронцем 
Талонна Отримання талону Отримати/ 10-20 секунд Середній 
на в'їзді, здача на відсканувати 
виїзді талон 
RFID Зчитування чіпу Піднести 2-3 секунди Високий 
брелок/карту 
ANRP Розпізнавання Дії відстутні 1-2 секунди Дуже високий 
номерного знака 
 Ручні системи повністю залежать від оператора. Втручання людини в 
процес знижує пропускну здатність. 
 Талонні системи частково автоматизують процес, але витрати часу на 
проїзд зменшуються не суттєво. Велика частка часу витрачається на отримання 
та сканування талону. 
 RFID-системи добре підходять для постійних клієнтів, але кожен 
пропуск потрібно видавати і адмініструвати. Швидкість проїзду при такій 
системі висока, за умови, що водій має пропуск на поготові. 
  ANRP усуває усі проміжні носії – ідентифікація відбувається за номером 
автомобіля. Підходить як для закритих так і комерційних автостоянок. 
Таблиця 2.  
Порівняння за витратами та експлуатацією 
Система Первинні витрати Експлуатаційні Ризики та 
витрати нероліки 
Ручна  Низькі Високі (заробітна Людський фактор, 
плата персоналу) суб’єктивність 
Талонна  Середні Середні/високі(папір, Втрата/передача 
обслуговування) талону, черги 
RFID Середні/високі Середні(випуск Втрата/передача 
карток) карток 
ANRP Середні(камера + Низькі Залежність від 
сервер) якості зображення 
13 
 
 Для автостоянок, де є великий потік автомобільного транспорту 
експлуатаційні витрати на персонал або талону є критичними. Тому в 
довгостроковій перспективі ANRP є найдешевшим рішенням, хоча потребують 
більших вкладень при впровадженні. 
Таблиця 3.  
Порівняння за безпекою та можливістю шахрайства 
Тип системи Можливість Можливість обману 
викрадення/передачі системи 
пропуску 
Ручна - Людський фактор та 
корупція 
Талонна Талон можна Можливість підробки 
викрасти/передати талону 
RFID Пропуск можна Можливість копіювання 
викрасти/передати карток 
ANRP Неможливо (номер Виключено при перевірці в 
прив’язаний до автомобіля) базі даних 
 RFID і талонні системи ідентифікують пропуск, а не автомобіль, що 
призводить до можливості обходу системи через передачу пропуска, чи 
підробок. ANRP ідентифікує сам транспортний засіб, шахрайство практично 
не можливе без втручання в базу даних. 
Таблиця 4.  
Порівняння можливості обліку і аналітики 
Тип системи Наявність автоматичного Можливість інтеграції з 
журналу обліку CRM/Smart City 
Ручна ✖ ✖ 
Талонна частково ✖ 
RFID частково частково 
ANRP Повна історія(фото, час) Можливість підключення 
API, хмарних сервісів  
 ANRP не лише контролює пропускну систему, а може збирати аналітичні 
дані, що дає можливість для подальшого впровадження Smart Parking. 
 Системи розпізнавання номерних знаків (ANRP) є найбільш 
ефективними для сучасних автостоянок, бо: 
• Забезпечують найвищу точність та швидкість ідентифікації 
• Не потребують фізичних пропусків та взаємодії з персоналом 
14 
 
• Майже повністю виключають шахрайство 
• Мінімізують експлуатаційні витрати 
 
1.3.  Технологія ANRP(Automatic Number Plate Recognition) та 
алгоритм розпізнавання номерних знаків 
 Технологія ANRP(Automatic Number Plate Recognition) – це технологія 
автоматичного виявлення та розпізнавання державних номерних знаків 
транспортних засобів за допомогою комп’ютерного зору та алгоритмів 
штучного інтелекту. Система аналізує зображення в реальному часі з камери, 
виділяє область номерного знака, розпізнає символи та порівнює отриману 
інформацію з базою даних дозволених автомобілів. 
ANRP сьогодні використовується на: 
• Автоматичних шлагбаумах автостоянок 
• Платних автомагістралях 
• КПП підприємств 
• Системах контролю порушення правил дорожнього руху 
Алгоритм складається з трьох основних етапів: 
• Детекція автомобіля та номерного знака (знаходження області 
номерного знаку на зображенні) 
• Передобробка фрагмента номерного знака ( бінаризація, фільтрація 
шумів, корекція геометрії) 
• Розпізнавання тексту номерного знаку (виділення та перетворення 
символів у текст) 
 Для виявлення номерних знаків на зображенні використовується 
сучасний алгоритм глибинного навчання для швидкого виявлення об’єктів на 
зображенні – YOLO(You Look Only Once). 
15 
 
 Принцип роботи YOLO: модель одним проходом аналізує кадр та видає 
координати об’єкта. Вхідний кадр розбивається на сітку з блоків, для кожного 
з яких прогнозуються: координати області, впевненість та клас. 
 Після детекції застосовується NMS(Non-Maximum Suppression) – 
алгоритм, що відкидає зайві рамки та залишає лише ту, яка має максимальну 
впевненість. 
 Перед подачею на OCR(розпізнавання символів) фрагмент з номерним 
знаком приводиться до стандартного вигляду: 
1. Перетворення у��( в��і,д��т)ін=ки0 с.2ір9о9г��о:+ 0.587�� + 0.114�� 
2. Бінаризація (метод ��Оℎт��с��у��): 
��2 ℎ������ = ������������������2(��) 
де �� — дисперсія міжкласового розділення. 
3. Нормалізація контрасту (CLAHE — Contrast Limited Adaptive Histogram 
Equalization). 
4. Видалення шумів (медіанний фільтр або Gaussian blur). 
5. Корекція перспективи (якщо номер під кутом). 
 Ці процедури покращують точність OCR, особливо за умов поганого 
освітлення. 
 Для розпізнавання символів використано Tesseract OCR з конфігурацією: 
--psm 7        # Розпізнання рядка тексту 
--oem 1        # Нейромережевий режим 
Додатково застосовується white-list символів: 
ABCDEFGHIKLMNOPRSTUVXYZ0123456789 
Це дозволяє системі ігнорувати «зайві» символи (краплі води, логотипи, 
артефакти). 
Отриманий номер�� ��п��о��р��ів��н=ює{т��ь��с����я ��з ,базою даних: 
��������, якщо ����������
якщо ���������� ∉∈ �������������������������������� 
16 
 
Якщо номер є в списку дозволених авто — шлагбаум відкривається 
автоматично. 
Кожна подія зберігається у базі даних разом із фото та часовою міткою. 
 Розпізнавання символів (OCR) — фінальний етап ANPR-конвеєра, який 
перетворює нормалізований фрагмент номерної пластини у символьний рядок. 
Від якості OCR залежить коректність доступу, тарифікації та звітності, тому 
модуль має бути стійким до шуму, кутів, відблисків та часткових перешкод. 
Підходи до OCR:  
1. Сегментаційні (classical OCR) 
Послідовність: бінаризація → виділення контурів → нормалізація 
символів → класифікація (kNN/SVM/Tesseract). 
Переваги: простота, низькі обчислювальні витрати. 
Недоліки: крихкість до перекосів/злипання символів, вимогливість до 
чіткості сегментації. 
2. Безсегментаційні (sequence models: CRNN/Transformers + CTC/Attention) 
Модель навчається розпізнавати цілий рядок як послідовність, без 
явного різання на символи. 
Переваги: стійкість до викривлень, різних шрифтів/інтервалів. 
Недоліки: потребує датасету, довшого навчання та обчислень. 
Практичний висновок: для прототипу достатньо Tesseract (класичний OCR) з 
правильною підготовкою; для production-рішень краще CRNN/Transformer-
OCR. 
Для стабільного розпізнавання фрагмент пластини приводять до стандарту: 
1. Перехід у сір����и��й�� ��к(а��н,а��л): = 0.299 �� + 0.587 �� + 0.114 �� 
2. Вирівнювання контрасту (CLAHE) та/або гамма-корекція �� ∈ [0.7; 1.4]. 
3. Бінаризація: От��с��у���� а(б��о, ��ад)а=пт��и{в����н��а�� (��G(��au, ��ss)ia>n/��M(e��a,n��)):}  
17 
 
4. Видалення шумів: медіанний/гаусовий фільтр, морфологія (open/close), 
top-hat. 
5. Геометрична нормалізація: deskew (Hough для горизонталей), perspective 
warp (гомографія). 
6. Масштабування до сталої висоти (наприклад, 32–48 px), anti-aliasing. 
Для налаштування Tesseract OCR використаємо параметри: 
--psm 7             # одна текстова лінія (рядок номера) 
--oem 1             # LSTM-based OCR engine 
-c tessedit_char_whitelist=ABCEHIKMOPTX0123456789 
 Для українських номерів доцільно обмежити алфавіт латинськими 
літерами, що візуально збігаються з кириличними: 
A, B, C, E, H, I, K, M, O, P, T, X та цифри 0–9. Це різко зменшує плутанину з 
літерами на кшталт S, Y, R, U, V, Z, які не використовуються у стандартних 
форматах UA-номерів. 
Додаткові корисні опції: 
• -c classify_bln_numeric_mode=1 (коли очікуємо перевагу цифр), 
• --dpi 300 (штучно підвищити dpi при подачі зображення), 
• нормалізація висоти символів (padding зверху/знизу до сталої H). 
Розглянемо безсегментаційний підхід до OCR – CRNN/Transformer-OCR: 
CRNN (Convolutional Recurrent Neural Network) поєднує CNN → RNN 
(BiLSTM) → Time-Distrℒibuted= D−enlns⁡e, н∑авчаєтьс��я( з�� C∣T��C)-втратою: 
������ ��∈ℬ−1(��)  
де ��— усі мℬожливі шляхи з «blank»-символами, що згортаються у мішень ��за 
операцією (видалення повторів і blank). 
Декодування: greedy (argmax на кожному кроці) або beam search з мовною 
моделлю (n-грам). 
Перевага: витримує перекоси, різні інтервали, часткові артефакти; краща 
точність на «важких» умовах. 
18 
 
 Точність системи автоматичного розпізнавання номерних знаків (ANPR) 
залежить від великої кількості зовнішніх та внутрішніх факторів. На якість 
впливають як умови зйомки, так і характеристики обладнання та алгоритмів. 
Система стає ефективною лише тоді, коли всі етапи — зйомка, детекція, OCR, 
постобробка — налаштовані узгоджено. 
 ANPR працює зі зображенням, тому різкі зміни освітлення можуть 
призводити до: 
• локальних пересвітів (відблиски фар), 
• недоекспонованості (темні ділянки), 
• зміни контрасту номера та фону. 
Найчастіше падіння точності OCR спостерігається вночі, коли номер 
«заливає» світлом фар. 
Щоб компенсувати цей фактор, використовують інфрачервону підсвітку та 
експозицію камери з авто-LDR. 
Також на точність OCR впливають погодні умови: 
• Дощ - краплі води можуть спотворити символи 
• Сніг - номер закривається снігом або льодом 
• Бруд - OCR помилково додає «шумові символи» 
• Туман / вологість - зменшується контрастність зображення 
Для таких умов системи застосовують мультикадрове голосування: якщо OCR 
сумнівається, знімаються кілька кадрів поспіль. 
Суттєвий вплив на OCR дає швидкість руху автомобіля. Чим швидше рух авто, 
тим більша розмитість через ��M��o��t��i��o��n ��B��l��u��r: ∼ �� ⋅ ����, 
де 
• ��
• ����— швидкість авто, 
— витримка експозиції камери. 
На КПП швидкість рекомендують обмежувати 10–15 км/год. 
19 
 
Останніми факторами, що впливають на точність є положення та 
налаштування камери. Якщо номер знятий під великим кутом, символи 
деформуються. 
Найкращі умови: 
• кут нахилу камери до площини номера не більше 15–20°, 
• висота установки камери: 1.7–2.2 м, 
оптимальна відстань: 4–7 м до зони зчитування. 
Базова вимога: номер має бути знятий так, щоб символи займали не менше 80 
px по висоті. 
Формально: ������ = ���������� ⋅ �� 
де 
• ����������— висота кадру, 
• �� — відстань, 
• — фокусна характеристика об’єктива. 
Камери з оптичним зумом працюють краще, ніж ширококутні. 
 Проблема дешевих камер — auto-focus hunting (камера «шукає» фокус), 
що руйнує кадри в момент в’їзду/виїзду. 
Рішення: 
• фіксований фокус (fixed focus), 
• окрема «зона фокусування», 
• фокус на відстань очікування. 
Якість результату залежить від: 
• точності локалізації номерної пластини (YOLO), 
• коректності OCR (Tesseract/CRNN), 
• постфільтрації та перевірки формату номера. 
В алгоритмах використовуються показники: 
• Precision (точність класу): 
20 
 
������������������ = ������+������ 
• Recall (повнота): ������������ = ������+������ 
де: 
• TP — знайдені правильно, 
• FP — хибні виявлення, 
• FN — пропущені. 
Сучасні моделі YOLOv5/YOLOv8 на спеціалізованих датасетах дають 
Precision ≥ 97 %. 
За останніми дослідженнями, суттєве покращення дають наступні методи: 
• CLAHE (вирівнювання гістограми) - підвищує контрастність 
• Adaptive thresholding - компенсує засвіт/тіні 
• Geometric deskew - виправляє перспективу 
• Multi-frame voting - підвищує точність OCR на 3–7% 
Точн��і��с��т��ь ��A��N����PR= м��о(ж��н��а�� о��п��и��с����а����ти, �� ф��у��н��к��ц����іє����ю����:�� �� , ���������������� , ������������ , ����������������) 
де: 
• ������������ ��������������— оптика + роздільність, 
• ������������������������������������— світло, погода, кут, 
• ������ — точність локалізації номера, 
• ⁡��������������������—��  похибка розпізнавання символів 
• — regex + голосування + whitelist. 
 Після сирого OCR застосовується валідація під формат номерів. Для 
поточних UA-форматів (спрощено): 
• ��Ди∈п{л��ом, ��н,о��-т, и��п, ��ов,и��й, �� ,ш��а,б��л,о��н, ��,л��ег}ко
, ��ви∈х{/з0 . .920}04 р.: LLNNNNLL, де 
. 
Регулярний вираз (UA-subset): 
21 
 
^[ABCEHIKMOPTX]{2}\d{4}[ABCEHIKMOPTX]{2}$ 
Типові плутанини та правила виправлення (context-aware): 
• 0 ↔ O, 1 ↔ I, 5 ↔ S, 8 ↔ B, 2 ↔ Z, 6 ↔ G 
• У буквених позиціях замінити цифри на схожі букви: 0→O, 1→I, 5→S(не 
в UA-subset), 8→B → але обмежити UA-subset! 
• У цифрових позиціях — зворотні заміни: O→0, I→1, B→8, Z→2. 
Щоб зменшити кількість помилок, застосовується: 
• whitelist — дозволити лише ті символи, що використовуються в UA-
номерах, 
• регулярний вираз (regex) формату номера 
• голосування по кількох кадрах (multi-frame voting). 
Приклад алгоритму валідації: 
1. Нормалізувати рядок до верхнього регістру, видалити пробіли/дефіси. 
2. Якщо не збігається з LLNNNNLL, виконати мінімальні контекстні 
заміни згідно позицій (буква/цифра). 
3. Повторно перевірити regex. Якщо успіх — прийняти; інакше — 
позначити як «невизначено» і вимагати повторного читання. 
Метрики якості OCR та оцінювання: 
• Accuracy рядка: частка повністю правильно розпізнаних номерів. 
• CER (Character Error Rate��)��: �� = �� + ���� + ��
 
де ��, ��, ��— заміни/видалення/вставки (редагування Левенштейна), ��— 
довжина еталону. 
• WER (Word Error Rate): для номерів (як «слово») менш показовий, але 
можна вказувати як додатковий. 
Звітність: бажано подавати accur. по підгрупах (день/ніч/дощ/кут), а також 
після постобробки (regex+правила) — зазвичай +2…5% до повного збігу 
рядка. 
22 
 
 Для підвищення надійності використовуються: мультикадрове 
голосування, «confidence gating» 
1. Confidence gating: якщо conf(OCR) < τ (поріг, напр. 0.75) або regex-
валідація не пройдена — запустити повторне зчитування або запросити 
ще 2–3 кадри. 
2. Мультикадрове голосування: агрегувати топ-кандидатів з 3–5 
послідовних кадрів: 
o позиційне голосування (по кожній позиції символу), 
o або n-best voting (узгоджувати найближчі рядки за відстанню 
Левенштейна). 
3. Історична пам’ять (context memory): якщо на в’їзді вже читали 
AA1234BB з високою впевненістю, а на виїзді отримали AA12348B — 
коригувати за попереднім еталоном (за умови часової близькості і 
відсутності конфліктів). 
 Щоб CRNN/Transformer добре «бачив» складні умови, у тренуванні 
застосовують: 
• Blur (Gaussian/Motion) — моделює рух/розфокус. 
• Noise (Poisson/Speckle), JPEG artifacts, констраст/експозиція. 
• Geometry: random affine/perspective, дрібні shear/rotate ±5–8°. 
• Occlusion: часткові перешкоди (бруд/рамка). 
• Fonts: варіювати шрифти та розміри, зберігаючи UA-subset. 
• Баланс класів: внутрішня мова номерів повинна мати рівномірні 
комбінації букв/цифр. 
Часті помилки та способи їх усунення: 
• Відблиски/пересвіт → локальна адаптивна бінаризація + обрізання 
highlight-ів; змінити кут/експозицію камери. 
• Розмиття рухом → обмежити швидкість до 10–15 км/год, коротша 
витримка, IR-підсвітка. 
• Забруднення/сніг → мультикадрове голосування, повторні кадри. 
• Плутанина O/0, I/1, B/8 → позиційні правила + regex UA-subset. 
23 
 
• Рідкісні формати (дипломатичні, спецсерії) → окремі regex-модулі та 
whitelist-и. 
Практичні рекомендації для нашої системи: 
• Для прототипу: Tesseract з --psm 7, whitelist UA-subset, агрегація з 3 
кадрів, regex-валідація і позиційні заміни. 
• Для бойового режиму: CRNN/Transformer-OCR з CTC, beam search + 
мовна модель для патернів номерів, активні аугментації при навчанні, 
кешування останніх «надійних» розпізнавань. 
 Правильна комбінація передобробки, OCR, постобробки за шаблоном, 
мультикадрової агрегації дозволяє істотно підвищити частку повністю 
правильних рядків. Для українських номерних знаків суттєве значення має 
алфавіт-підмножина (UA-subset) та контекстні правила підстановок, що 
мінімізують плутанини між схожими літерами та цифрами. 
 
1.4. Аналіз сучасних систем контролю доступу та комерційних 
ANPR-рішень 
 Сучасні системи контролю доступу для автомобілів є важливим 
елементом інтелектуальної інфраструктури підприємств, житлових 
комплексів, логістичних хабів та автостоянок. Розвиток цифрових технологій 
та відеоаналітики зумовив суттєву еволюцію таких систем: від простих 
механічних шлагбаумів із ручним керуванням до повністю автоматизованих 
комплексів, здатних самостійно ідентифікувати транспортні засоби, вести 
журнали подій, формувати статистичні звіти і передавати дані до хмарних 
сервісів. 
 Аналіз сучасних рішень демонструє, що ринок систем контролю доступу 
сьогодні охоплює різні за складністю та вартістю варіанти: від 
низькобюджетних систем із базовою функціональністю до 
високотехнологічних платформ, що включають в себе відеоаналітику, білінг, 
бухгалтерію, інструменти розпізнавання номерних знаків та інтелектуальний 
24 
 
моніторинг. Сучасні комплекси вже не обмежуються розпізнаванням номерів 
авто, а інтегрують різні технології: RFID-мітки, QR-коди, мобільні додатки, 
NFC, системи зважування транспортних засобів та навіть біометричні 
механізми доступу. 
 Традиційні системи доступу, які домінували протягом багатьох років, 
передбачали присутність охоронця або оператора, який вручну відкривав 
шлагбаум та фіксував проїзд автомобілів. Такі системи були простими, але 
мали низку недоліків: вони повністю залежали від людського фактора, не 
забезпечували цифрової реєстрації подій, були схильні до помилок та 
зловживань і не забезпечували можливості аналітики. Поява карткових систем 
та RFID-міток частково вирішила проблему, однак такі рішення лишаються 
вразливими до передачі карт стороннім особам, фізичного зносу носіїв та 
недосконалої ідентифікації. 
 Поширення комп’ютерного зору та штучного інтелекту спричинило 
перехід до нового покоління систем — комплексів на основі автоматичного 
розпізнавання номерних знаків (ANPR). Такі системи мають кілька 
фундаментальних переваг: вони не потребують від користувачів жодних 
фізичних носіїв, забезпечують повну фото- і відеофіксацію подій, легко 
інтегруються з базами даних та системами керування. Крім того, ANPR 
дозволяє автоматизувати процес повністю, що робить систему швидшою, 
безпечнішою та надійнішою. 
 Огляд світових і українських комерційних рішень показує, що більшість 
виробників рухаються у напрямку повної автоматизації процесів доступу з 
мінімальною участю персоналу. При цьому загальний підхід до реалізації 
таких систем має схожу структуру: камера фіксує зображення номерного знака, 
програмне забезпечення виконує розпізнавання, система ухвалює рішення і, за 
потреби, відкриває шлагбаум. 
 Проте на ринку спостерігається значна різниця між реалізаціями. Одні 
виробники інтегрують модуль розпізнавання безпосередньо в камеру, що 
дозволяє зменшити навантаження на сервери і спрощує інфраструктуру. Інші 
25 
 
використовують зовнішні сервери або хмарні платформи, які виконують аналіз 
зображень централізовано. Кожен підхід має свої переваги й обмеження. Edge-
аналітика зменшує затримки і навантаження, проте гірше масштабується. 
Хмарні сервіси забезпечують масштабність, але вимагають стабільного 
інтернету та несуть ризики конфіденційності. 
 Серед провідних виробників обладнання для паркувальних систем 
можна відзначити Hikvision, Dahua, Axis, Nedap, CAME, Skidata, а також 
численні хмарні сервіси, такі як OpenALPR та PlateRecognizer. Вони 
пропонують різні стратегії впровадження ANPR. 
 Hikvision і Dahua орієнтуються на масовий ринок та інтегрують модуль 
розпізнавання безпосередньо в камеру. Такі рішення зручні, оскільки не 
потребують додаткового серверного обладнання. Однак точність таких систем 
залежить від можливостей вбудованого процесора камери, і тому вони мають 
обмеження щодо складних умов зйомки чи унікальних форматів номерних 
знаків. 
 Axis пропонує інтелектуальні камери преміум-класу, орієнтовані на 
критично важливі об’єкти, де точність і стабільність важливіші за вартість. Їх 
системи дозволяють завантажувати власні алгоритми, однак коштують значно 
дорожче, ніж середньоринні аналоги. 
 Хмарні сервіси, такі як OpenALPR, працюють за моделлю SaaS і 
дозволяють передавати зображення на сервер для розпізнавання. Перевагою 
таких систем є їх гнучкість і простота інтеграції, але вони залежать від 
інтернету і не завжди придатні для закритих корпоративних мереж, де важлива 
приватність даних. 
 Українські рішення (UkrPark, Інтелект Парк та ін.) адаптовані під місцеві 
формати номерів і мають переваги щодо локалізації та підтримки, проте часто 
є закритими системами, які важко інтегрувати з іншими платформами або 
кастомізувати під специфічні задачі бізнесу. 
 
 
26 
 
Таблиця 5.  
Порівняння комерційних рішень. 
Параметр / Hikvision Dahua Axis Nedap CAME / 
Система Communicati uPASS Parkare 
ons 
Тип системи Камери з Камери з Преміум IP- Далекобійн Гібридні 
вбудованим ANPR + камери з а UHF- RFID/ANPR 
ANPR паркувальні відкритим ідентифіка рішення 
системи SDK ція 
Технологічни Edge- Edge + Можливість RFID/UHF Поєднання 
й підхід розпізнаван серверне завантаження мітки 5–10 карт, QR, 
ня в камері розпізнаван власних м OCR 
ня моделей 
Точність 92–96 % 90–95 % 94–98 % Не Залежить 
розпізнаванн розпізнає від ПЗ, 85–
я номерів номери 94 % 
Стійкість до Середня: Середня Висока Дуже Середня 
погодних залежить (преміум висока 
умов від моделі сенсори) (RFID) 
камери 
Необхідність Ні Ні Ні Ні Ні 
стабільного 
інтернету 
Можливість Так Так Так Так Так 
локального 
встановлення 
(on-premise) 
Гнучкість Низька Обмежена Висока Немає Середня 
налаштуванн (закритий (розширювани
я алгоритмів софт) й SDK) 
Інтеграція Є, але Є Розвинена Є Частково 
через API обмежена API-
інфраструктур
а 
Можливість Обмежена Обмежена Добра Непридатна Частково 
кастомізації 
під локальні 
формати 
номерів 
Необхідне Необов'язко Іноді Необов'язково Не Залежить 
серверне во потрібне від 
обладнання комплексу 
Продуктивніс 20–30 20–30 30–40 До 60 10–20 
ть 
(авто/хвилин
у) 
Затримка ~1–2 с ~1–2 с <1 с <0.5 с 1–3 с 
ухвалення 
рішення 
27 
 
Повна Низька / Низька / Висока Середня Середня 
вартість середня середня 
впровадженн
я (приблизно) 
Переваги Простота, Інтеграція з Максимальна Стійкість Гібридність 
доступність білінгом гнучкість і та і надійність 
, edge- якість швидкість 
ANPR 
Недоліки Закриті Менш Дороге Не Складність 
алгоритми точне OCR обладнання розпізнає налаштуван
номерні ня 
знаки 
Порівняємо комерційні рішеня з розроблюваною системою: 
Таблиця 6.  
Порівняння комерційних систем з розроблюваною 
Критерій Комерційні системи Розроблювана система 
ANPR 
Вартість впровадження висока (2500–6000$ на низька (камери + miniPC / 
один КПП) Jetson) 
Гнучкість залежність від виробника повна кастомізація 
Можливість зміни закритий код open-source (YOLO + OCR) 
алгоритму 
База даних часто закрита власна БД + API 
Інтеграція обмежена нескінченна (REST API, CRM, 
SCADA) 
 Проведений огляд демонструє, що попри розмаїття доступних рішень, 
жодна з комерційних систем не є універсальною. Більшість продуктів або 
надто закриті, або не дозволяють повноцінно адаптувати алгоритми під 
локальні умови, або є занадто дорогими для невеликих об’єктів. Тому 
створення власної системи на базі відкритих технологій та таких інструментів 
як Python, YOLO, OpenCV, Tesseract і FastAPI є економічно виправданим та 
технічно перспективним рішенням. 
Такий підхід дозволяє: 
• повністю контролювати алгоритми розпізнавання, 
• адаптувати систему під нестандартні умови зйомки, 
• вносити зміни у правила доступу та структуру бази даних, 
• інтегрувати систему з локальними обліковими або платіжними 
сервісами, 
• знизити витрати на ліцензії. 
28 
 
 Таким чином, аналіз сучасних та комерційних систем підтверджує 
актуальність розробки власної адаптивної ANPR-платформи, яка поєднує 
точність, відкритість коду та можливості масштабування. 
 
 1.5. Висновок до розділу 1 
 У першому розділі кваліфікаційної роботи виконано комплексний 
аналітичний огляд сучасних підходів до організації систем автоматизованого 
доступу транспортних засобів на автостоянки. На основі вивчення 
літературних джерел, технічної документації виробників ANPR-систем та 
порівняння комерційних рішень було встановлено низку закономірностей і 
тенденцій у розвитку таких систем. 
 Аналіз показав, що історично контроль доступу на стоянках розвивався 
від повністю ручних систем до рішень із частковою та повною автоматизацією. 
Ручні методи (введення даних оператором, пропуск за візуальною перевіркою) 
є найбільш ненадійними, оскільки мають високу залежність від людського 
фактора, низьку пропускну здатність і відсутність можливості ведення 
автоматичного обліку подій. Подальше впровадження талонних і RFID-систем 
дозволило автоматизувати процес фізичного доступу, однак ці системи 
залишили низку недоліків: потребу у фізичному носії, ризик шахрайства 
(передача карток стороннім), неможливість однозначної ідентифікації 
конкретного транспортного засобу. 
 В результаті еволюції виник сучасний підхід — ANPR (Automatic 
Number Plate Recognition), що базується на технологіях комп’ютерного зору та 
штучного інтелекту. Проведений огляд показав, що ANPR дозволяє повністю 
усунути фізичні носії пропусків, здійснювати безконтактний доступ, 
автоматично вести облік усіх подій та формувати аналітичні звіти. У 
підрозділах 1.3–1.5 детально розглянуто алгоритми розпізнавання, включаючи 
використання нейронних мереж (YOLO) для детекції номерних знаків та OCR-
технологій для розпізнавання символів, з урахуванням постобробки, 
контекстних корекцій та форматної валідації номерів. 
29 
 
 Було проаналізовано фактори, які впливають на точність ANPR: умови 
освітлення, погодні фактори, швидкість руху автомобіля, правильність вибору 
камери та параметри її встановлення, а також якість попередньої обробки 
зображення. Показано, що за оптимальних умов (правильний кут та відстань 
камери, використання нейронної детекції, мультикадрове голосування) 
точність розпізнавання може досягати 95–99 %. 
 Окрему увагу було приділено аналізу комерційних ANPR-рішень 
(Hikvision, Dahua, Axis, ARH, OpenALPR, PlateRecognizer). Проведене 
порівняння продемонструвало, що існуючі системи мають високу якість, проте 
значною проблемою є vendor lock-in, висока вартість впровадження та 
обмежена можливість кастомізації. Універсальні системи Smart Parking, що 
використовують ANPR, орієнтовані переважно на великі інфраструктурні 
проєкти (ТРЦ, аеропорти, муніципальні паркінги), що не дозволяє їх 
економічно доцільно впроваджувати на невеликих автостоянках та приватних 
об’єктах. 
 ANPR є найбільш ефективним, точним та економічно обґрунтованим 
підходом для автоматизації доступу транспортних засобів на автостоянки 
завдяки безконтактності, повній автоматизації, можливості інтеграції з 
обліковими системами та відсутності необхідності у фізичних пропусках. 
 Отримані у першому розділі результати створюють теоретичну основу 
для подальшого проєктування системи. На їх основі у наступному розділі буде 
розроблено архітектуру системи контролю доступу, обрано методи реалізації 
програмної та апаратної частин, побудовано базу даних та алгоритми обробки 
даних ANPR. 
  
30 
 
РОЗДІЛ 2. ПРОЄКТУВАННЯ СИСТЕМИ АВТОМАТИЗОВАНОГО 
ДОСТУПУ І ОБЛІКУ АВТОМОБІЛІВ НА АВТОСТОЯНЦІ 
 2.1. Постановка задачі 
 Метою кваліфікаційної роботи є розроблення системи автоматизованого 
доступу та обліку автомобілів на автостоянці з використанням технології 
розпізнавання державних номерних знаків (ANPR), що забезпечуватиме 
безконтактний пропуск транспортних засобів та автоматичне ведення журналу 
подій. 
 У більшості існуючих систем контролю доступу на автостоянках 
застосовуються або RFID-пропуски, або талонні механізми, що мають низку 
недоліків: 
• необхідність видачі та адміністрування пропусків, 
• можливість передачі RFID-мітки сторонній особі, 
• залежність від людського фактору (оператор відкриває шлагбаум 
вручну), 
• відсутність автоматичного обліку часу перебування транспортного 
засобу. 
 Сучасний підхід полягає в ідентифікації не пропуску, а автомобіля, через 
аналіз зображення з відеокамери і розпізнавання номерного знака. 
На автостоянках виникає потреба в: 
• контролі в'їзду та виїзду транспортних засобів, 
• автоматичному відкриванні шлагбаума без участі людини, 
• веденні обліку часу перебування автомобіля на стоянці, 
• збереженні фотофіксації фактів в'їзду/виїзду, 
• можливості інтеграції з платіжними системами. 
Відсутність автоматизації призводить до: 
• затримок при в’їзді/виїзді, 
• помилок при ручному внесенні даних, 
• неможливості контролю сторонніх транспортних засобів, 
• труднощів у генерації статистики завантаженості 
31 
 
 Метою проєкта є: створити автоматизовану систему доступу на 
автостоянку, у якій ідентифікація автомобіля здійснюється на основі 
розпізнавання номерного знака з відеопотоку камери, та на основі цього 
відбувається відкриття шлагбаума і ведення обліку. 
Для досягнення мети необхідно: 
1. Розробити архітектуру системи (апаратна та програмна частини). 
2. Вибрати алгоритми обробки зображення: 
3. Реалізувати модуль передобробки зображення (фільтрація, бінаризація, 
нормалізація). 
4. Створити базу даних для: 
5. Реалізувати програмний модуль доступу: 
6. Розробити інтерфейс адміністратора: 
7. Протестувати систему за різних умов (день/ніч/дощ, швидкість авто). 
8. Провести аналіз точності алгоритму ANPR та визначити межі 
застосування. 
 Сформульована задача передбачає створення інтелектуальної системи 
доступу, здатної самостійно розпізнавати номерні знаки, приймати рішення та 
автоматично вести облік. 
 
2.2. Функціональні вимоги до системи 
 Функціональні вимоги визначають, що саме повинна робити система, які 
функції реалізовуються для користувача, адміністратора та зовнішніх систем. 
У цьому підрозділі сформовано набір функцій, що забезпечують 
автоматизований доступ транспортних засобів на автостоянку з 
використанням ANPR. 
Система повинна забезпечувати виконання таких ключових функцій: 
1. Захоплення відеопотоку з IP-камери в зоні в’їзду/виїзду. 
2. Детекція транспортного засобу у кадрі. 
3. Виявлення та сегментація номерної пластини з відео/зображення. 
32 
 
4. Розпізнавання номерного знака (OCR) та перетворення його у 
символьний рядок. 
5. Перевірка номерного знака у базі даних системи. 
6. Автоматичне відкриття шлагбаума, якщо номер присутній у списку 
дозволених. 
7. Фіксація події (в'їзд/виїзд) із включенням: 
o фото кадру з номером, 
o розпізнаного номера, 
o часу та дати. 
8. Збереження інформації у журнал подій (в БД). 
9. Відображення подій у веб-інтерфейсі адміністратора. 
Адміністратор має мати інструменти керування автостоянкою 
• Управління списком дозволених автомобілів - 
додавання/видалення/редагування номерів 
• Перегляд журналу подій - фільтрація за датою, годиною, статусом (в'їзд 
/ виїзд) 
• Пошук номерів - за фрагментом тексту або номером авто 
• Перегляд фотофіксації події - доступ до фрагмента кадру з номером 
• Керування шлагбаумом - дистанційне відкриття через web-інтерфейс 
• Експорт даних - формування звітів CSV/XLSX (за потреби) 
• Управління користувачами - створення ролей (admin/operator)  
Система повинна мати базу даних з такими можливостями: 
Vehicles (дозволені авто) номер авто, власник, статус доступу 
Events (журнал подій) номер авто, тип події (в'їзд/виїзд), час, фото 
Users (користувачі системи) логін, пароль, роль 
База даних повинна підтримувати: 
• зберігання історії подій протягом тривалого періоду, 
• запити на фільтрацію та сортування (SQL), 
33 
 
• автоматичну реєстрацію часу події (timestamp).  
 
 2.3. Нефункціональні вимоги та обмеження системи 
 Нефункціональні вимоги визначають якість роботи системи, параметри 
продуктивності, надійності, безпеки та зручності експлуатації. Вони не 
описують, що робить система, а описують як вона повинна працювати. 
Вимоги до продуктивності: 
• Час обробки одного кадру з камери — не більше 2 секунд від моменту 
фіксації номерного знака до прийняття рішення про відкриття 
шлагбаума. 
• Система повинна підтримувати обробку відеопотоку 25–30 FPS (RTSP). 
• Допускається затримка зчитування кадру не більше 200 мс при 
нестабільному каналі зв'язку. 
• Час відкриття шлагбаума після підтвердження доступу — до 1 секунди. 
Загальна затримка від появи авто до відкриття шлагбаума не повинна 
перевищувати 3 секунд. 
Вимоги до надійності: 
• Система повинна працювати 24/7, без втручання оператора. 
• У разі втрати зв’язку з камерою ANPR-модуль має виконати автоматичне 
перепідключення. 
• Усі події (в'їзд/виїзд) зберігаються в базі даних із timestamp та 
фотофрагментом. 
• У випадку відмови OCR / неуспішного розпізнавання: 
o робиться повторне зчитування з 3–5 кадрів, 
o якщо неможливо розпізнати — виконується логування інциденту 
та передається сигнал оператору. 
Таблиця 7.  
Безпека та захист даних 
Об’єкт захисту Вимога 
Доступ до системи авторизація користувачів (JWT / session based) 
34 
 
Передача даних з камери шифрування HTTPS/RTSP over TLS (за потреби) 
База даних резервне копіювання + контроль доступу за ролями 
Логування подій запис усіх вхідних/вихідних запитів, дій адміністратора 
Дані про автомобілі є конфіденційними, тому система повинна забезпечувати: 
аутентифікацію, авторизацію, захист від несанкціонованого доступу. 
Вимоги до інтерфейсу користувача: 
• Інтерфейс повинен бути web-орієнтованим та доступним у браузері. 
• Доступні ролі користувачів: 
o Адміністратор — повний доступ, 
o Оператор — перегляд журналу, відкриття шлагбаума вручну. 
• Інтерфейс повинен забезпечувати: 
o відображення в реальному часі статусу камери, 
o журнал подій із пошуком по номеру авто, 
o можливість додавання/видалення номерів зі списку доступу. 
Вимоги до обладнання: 
Таблиця 8.  
Вимоги до обладнання 
Компонент Вимога 
Камера IP-камера з підтримкою RTSP, FullHD ≥ 1920×1080, IR-
підсвітка 
Сервер / MiniПК CPU ≥ 4 ядра або GPU Jetson / CUDA (для нейронних моделей) 
Контролер інтерфейс управління: GPIO / RS485 / Modbus / HTTP API 
шлагбаума 
Мережа стабільний Ethernet або Wi-Fi 5/6, пропускна здатність ≥ 20 
Мбіт/с 
Обмеження системи: 
• Автомобіль повинен рухатись зі швидкістю не більше 15 км/год у зоні 
зчитування. 
• Номерний знак повинен бути видимим та відповідати стандарту країн 
формату UA. 
• Камера встановлюється під кутом не більше 20° до площини номерної 
пластини. 
 
 
35 
 
 2.4. Обґрунтування вибору обладнання 
 Проектування системи автоматизованого доступу транспортних засобів 
на автостоянку з використанням технології ANPR (Automatic Number Plate 
Recognition) передбачає ретельний вибір технічних засобів, що забезпечують 
точність і стабільність роботи. На відміну від традиційних систем контролю 
доступу, системи ANPR мають значну залежність від параметрів зйомки, 
пропускної здатності обчислювального вузла та надійності мережевої 
інфраструктури. Тому вибір обладнання повинен ґрунтуватися на 
функціональних і нефункціональних вимогах зокрема таких як точність 
розпізнавання, швидкодія, доступність резервування та робота у 
безперервному режимі 24/7. 
 Вибір відеокамери як головного джерела даних: У системах ANPR саме 
відеокамера є ключовим елементом, що визначає верхню межу точності. 
Навіть найкращий алгоритм не здатний компенсувати низьку якість вхідного 
зображення. Саме тому вимоги до камери формуються не загальними 
міркуваннями, а математично визначеними параметрами: роздільна здатність, 
розмір символів на матриці, співвідношення сигнал/шум, здатність до роботи 
у нічному режимі. 
Таблиця 9.  
Критерії вибору камери 
Критерій Мінімальна вимога Обґрунтування 
Роздільна FullHD (1920×1080) Для забезпечення висоти символів 
здатність номерного знака ≥ 80 px 
Чутливість уночі IR-підсвітка + ICR- Для коректної роботи камери у режимі 24/7 
фільтр 
Спосіб передачі RTSP Забезпечує сумісність із Python/ANPR-
даних модулями 
Фокусна відстань 4–12 мм (varifocal) Налаштування кадру під реальну відстань 
до авто 
Монтажний кут ≤ 20° до площини Мінімізація перспективних спотворень 
номера 
 Оскільки OCR-модуль розпізнає символи з урахуванням їх чіткості та 
висоти у пікселях, число 80 px не є умовним — це експериментально 
визначений мінімум для стабільного розпізнавання латинських і кириличних 
36 
 
символів. Камера нижчої роздільної здатності змусила б збільшувати фокусну 
відстань, зменшуючи кут огляду, що негативно впливає на пропускну здатність 
КПП. 
 Обрана камера - IP-камера з ІЧ-підсвіткою, варіофокальним об’єктивом 
та підтримкою RTSP. 
Такі моделі забезпечують: стабільну роботу у денному й нічному режимі, 
правильний рівень експозиції, можливість індивідуального налаштування 
фокусу під конкретний КПП. 
На практиці підходять моделі класу: Hikvision DS-2CD2T47G2-L, Dahua 
WizMind Series. 
Ці камери дозволяють отримати достатню якість для ANPR без надмірної 
вартості. 
 Вибір обчислювального модуля (ANPR-ядра): Обчислювальний модуль 
виконує найскладніші операції системи: аналіз відеопотоку, детекцію 
номерного знака, сегментацію ROI і OCR-розпізнавання. Від його 
продуктивності залежить: 
• кількість потоків, що обробляються одночасно, 
• затримка між виявленням авто і передачею сигналу на шлагбаум, 
• енергоефективність та нагрівання системи. 
Таблиця 10.  
Порівняння обчислювальних платформ 
Варіант Переваги Недоліки Придатність 
ПК (Intel i5/i7) Висока швидкість, Високе Надлишковий для 
обробка 3–6 камер енергоспоживання 1–2 камер 
MiniPC (Core Компактний, Не підходить для AI- Найкращий 
i3/i5, 8–16 GB безшумний, достатня обробки 5+ камер баланс 
RAM) швидкість 
NVIDIA Jetson Висока швидкість Вища ціна, складніша Ідеально для real-
Nano/Xavier YOLO через GPU конфігурація time ANPR 
 Для кваліфікаційного проєкту доцільно використовувати MiniPC або 
NVIDIA Jetson Nano. MiniPC забезпечує низьке енергоспоживання, 
стабільність і простоту налаштування. Jetson Nano забезпечує апаратне 
прискорення нейронних мереж, що дозволяє: 
37 
 
• виконувати YOLOv5/YOLOv8 на швидкостях 25–30 FPS, 
• зменшити затримку до <0.5 с, 
• працювати одразу з двома потоками. 
Таким чином, Nvidia Jetson Nano є оптимальним варіантом при необхідності 
високої продуктивності. 
 Шлагбаум — виконавчий механізм, який повинен отримати команду від 
ANPR-системи та відкритися у випадку позитивного рішення. Вибір 
контролера визначає стабільність і безпеку роботи всього комплексу. Можливі 
варіанти: 
• GPIO-виходи MiniPC/Jetson забезпечують найпростіший спосіб 
керування, однак вимагають галванічної розв’язки та ретельного 
налаштування. 
• RS485/Modbus — промисловий стандарт, який забезпечує високу 
надійність та стійкість до перешкод. 
• IP-контролери з HTTP API є найбільш зручними для інтеграції, але 
потребують стабільної мережевої інфраструктури. 
 У кваліфікаційному проєкті використовується релейний модуль, 
підключений до MiniPC або Jetson через USB-GPIO. Такий спосіб дозволяє: 
• виконувати керування у реальному часі, 
• забезпечити просту логіку: 1 = відкрити, 0 = закрити, 
• залишити можливість резервного ручного керування. 
Серверна частина відповідає за: 
• зберігання журналів проїзду, 
• зберігання зображень, 
• авторизацію транспортних засобів, 
• журналювання, 
• API-взаємодію між фронтендом та ANPR-модулем. 
Для кваліфікаційного проєкту достатньо SQLite, оскільки вона не потребує 
окремого сервера і забезпечує достатню швидкість. 
38 
 
 Надійність мережевої інфраструктури впливає на затримку та якість 
роботи. Тому необхідною є: 
• PoE-комутатор — живлення камери через Ethernet, 
• UTP-кабель cat.5e/6 — для стабільної передачі відео, 
• UPS 650–1200 ВА — забезпечує 15–40 хвилин автономної роботи. 
Наявність резервного живлення критично важлива, оскільки вимкнення 
живлення може заблокувати прохід автомобілів. 
У підсумку обране обладнання має такі характеристики: 
• Середній час обробки - 1–2 секунди 
• Точність розпізнавання номерів - ≥ 95% 
• Робота в режимі 24/7 – Гарантована 
• Масштабованість - До кількох камер та КПП 
• Надійність - Висока завдяки резервуванню 
Комплект підібраний так, щоб уникнути залежності від одного виробника, 
дозволити подальше масштабування та забезпечити повний контроль над 
алгоритмами ANPR. 
 Підібране обладнання повністю відповідає технічним і експлуатаційним 
вимогам, забезпечує необхідну точність, продуктивність та надійність 
системи. Обрані компоненти дозволяють будувати модульну, масштабовану та 
автономну систему ANPR, адаптовану до умов реальної експлуатації 
автостоянок, КПП і логістичних об'єктів. 
 
 2.5. Архітектура системи 
 Архітектура системи автоматизованого доступу на базі ANPR визначає 
логічну структуру програмних та апаратних компонентів, способи їх взаємодії, 
потоки даних, а також правила прийняття рішень на рівні edge-вузла. На 
відміну від централізованих або хмарних рішень, побудова ANPR-комплексу 
для автостоянки вимагає локальної (edge-first) обробки відеопотоку, оскільки 
39 
 
затримка в декілька секунд може призвести до аварійних ситуацій, 
накопичення черг і зниження пропускної здатності. 
 Запропонована архітектура побудована за модульним принципом. Кожен 
компонент системи відповідає за чітко визначену функцію: прийом 
відеопотоку, детекцію номерної пластини, OCR-розпізнавання, постобробку, 
ухвалення рішення, керування шлагбаумом, ведення журналів і 
адміністрування користувачів. Завдяки розділенню відповідальностей система 
добре масштабується, легко підтримується та дозволяє замінювати окремі 
модулі (наприклад, оновлювати модель YOLO чи OCR-двигун без зміни інших 
компонентів). 
 На найвищому рівні абстракції (architecture level 0) система складається 
з трьох основних вузлів: джерела даних (IP-камера), ядра обробки (ANPR-
модуль) та виконавчих механізмів (шлагбаум, БД, веб-інтерфейс). 
Ключові принципи архітектури: 
1. Edge-first. Усі критичні рішення (Allow/Deny) виконуються локально, 
без взаємодії з хмарою. Це знижує затримку та вирішує проблему 
конфіденційності. 
2. Подієва модель. Кожна подія (в’їзд/виїзд) є атомарною і 
супроводжується фіксацією: номер, час, фотофрагмент, рішення. 
3. Строге розділення відповідальностей. Модуль відео не знає про логіку 
доступу, а API не втручається в роботу OCR. Це забезпечує прозорість і 
стабільність. 
4. Виявлення та самовідновлення. При збоях RTSP, БД чи реле система 
переходить у безпечні стани. 
Основні компоненти системи: 
• Модуль відео: приймає RTSP-потік, виконує декодування та 
буферизацію кадрів із мінімальною затримкою. 
• Модуль детекції: знаходить номерну пластину за допомогою YOLO та 
передає ROI у наступні етапи. 
40 
 
• Модуль передобробки: нормалізація зображення, корекція яскравості, 
геометричне вирівнювання. 
• OCR: Tesseract або CRNN виконує розпізнавання символів. 
• Постобробка: перевірка регулярним виразом, мультикадрове 
голосування, фільтри достовірності. 
• Модуль доступу: виконує логічне правило доступу, працює з політиками, 
тарифами та статусами авто. 
• База даних: зберігає події, користувачів, правила доступу. 
• REST API: забезпечує інтеграцію веб-інтерфейсу та зовнішніх систем. 
• Контролер шлагбаума: реалізує фізичне відкриття/закриття. 
 Після визначення загальної архітектури системи необхідно деталізувати, 
як саме дані переміщуються між окремими модулями та які перетворення 
відбуваються на кожному етапі. Data Flow Diagram (DFD) рівня 1 дозволяє 
представити систему не як статичну сукупність компонентів, а як динамічну 
структуру, де кожен модуль виконує конкретну функцію з обміну даними. 
1. Потік «Відео» 
Джерело:IP-камера 
Призначення: отримання необроблених кадрів для аналізу 
1. Камера надсилає потік відеоданих через RTSP. 
2. Модуль прийому кадрів декодує потік і формує чергу (frame buffer). 
3. Детектор номерної пластини (YOLO) отримує кадр та виділяє одну або 
кілька ROI. 
4. Виділені області надсилаються у модуль попередньої обробки (CLAHE, 
normalize, warp). 
5. Далі зображення передається у OCR-двигун (Tesseract або CRNN), де 
генерується текстовий рядок. 
Завершення потоку: 
Потік «Відео» закінчується формуванням кандидатного рядка номерного 
знака, який переходить у потік «Рішення». 
2. Потік «Рішення» 
41 
 
Джерело: модуль OCR → текст номерного знака 
Призначення: визначити, чи автомобіль має право на в’їзд/виїзд 
1. Текст номерного знака передається до модуля постобробки (валидація, 
regex, голосування). 
2. Якщо номер відповідає вимогам формату та має достатню впевненість, 
він надсилається у БД. 
3. Модуль доступу виконує запит: 
«чи номер присутній у списку дозволених?» 
4. Залежно від статусу (active, blocked, guest, expired) формується рішення. 
5. Модуль доступу повертає один із двох результатів: Allow або Deny. 
Завершення потоку: 
Рішення передається в модуль керування шлагбаумом. 
3. Потік «Управління шлагбаумом» 
Джерело: модуль доступу 
Призначення: фізично виконати команду 
1. Якщо рішення — Allow, то ANPR-ядро викликає функцію open() через 
GPIO/HTTP/RS485. 
2. Шлагбаум переходить у стан OPENING → OPEN → CLOSING. 
3. Якщо рішення — Deny, команда не надсилається, а в UI формується 
відповідне повідомлення. 
4. Сигнали від фотоелементів передаються назад до ядра, щоб забезпечити 
режим anti-tailgating. 
 Схема даних визначає логічну структуру інформації, що зберігається у 
системі контролю доступу, та описує взаємозв’язки між сутностями. Оскільки 
ANPR-система є подієвою, а її основною функцією є обробка в’їздів і виїздів 
транспортних засобів, структуру бази даних необхідно будувати таким чином, 
щоб забезпечити: 
1. швидкий пошук номерних знаків, 
2. можливість формування історичних звітів, 
3. цілісність та уніфікацію інформації, 
42 
 
4. розмежування прав доступу, 
5. аудит усіх адміністративних операцій. 
 Система не потребує надмірно складної моделі даних, проте вона 
повинна включати набір сутностей, який покриває повністю функціональні та 
нефункціональні вимоги. На основі цього сформовано мінімальний, але 
повноцінний набір таблиць: 
1. vehicles — реєстр транспортних засобів 
Це одна з ключових таблиць системи, яка містить інформацію про всі 
автомобілі, що мають або можуть мати доступ. 
Основні поля: 
• id — унікальний ідентифікатор; 
• plate — номерний знак у канонічному форматі (AA1234BB); 
• owner — ПІБ власника або назва організації; 
• status — active, blocked, guest, expired; 
• notes — коментар (наприклад, "тимчасовий доступ до кінця місяця"); 
• created_at — дата створення запису. 
Ця таблиця використовується модулем доступу при ухваленні рішень 
Allow/Deny. 
2. events — історія подій проїзду 
Таблиця фіксує кожний факт в’їзду або виїзду. Кожна подія є атомарною. 
Основні поля: 
• id, 
• ts — точна мітка часу, 
• plate — розпізнаний номер, 
• direction — entry або exit, 
• decision — allow/deny, 
• image_path — шлях до збереженого фото, 
• conf_det — впевненість детектора YOLO, 
• conf_ocr — впевненість OCR. 
43 
 
Ця таблиця є основою для аналітичних модулів: 
завантаженість стоянки, пропускна здатність КПП, пікові години. 
3. users — облікові записи користувачів 
Система повинна забезпечувати повноцінний контроль доступу до інтерфейсу. 
Поля: 
• id, 
• username, 
• password_hash — збережений у вигляді хешу (bcrypt/argon2), 
• role — admin, operator, viewer, 
• created_at. 
Система не зберігає паролі у відкритому вигляді. 
4. access_rules — правила доступу та маски номерів 
Таблиця дозволяє налаштувати більш гнучку логіку доступу. 
Можливі поля: 
• plate_mask — шаблон, 
• schedule — часові інтервали доступу (наприклад, будні 9:00–18:00), 
• rule_type — allow / deny. 
Це дає змогу налаштовувати складні сценарії: 
наприклад, дозволити доступ службовому транспорту тільки уночі. 
5. audit_logs — аудит дій адміністраторів 
Це вимога безпеки. Усі зміни у списках авто, правилах або конфігурації 
фіксуються. 
Поля: 
• user_id, 
• action, 
• ts, 
• payload — детальний опис змін. 
Це забезпечує відстеження дій операторів у разі спірних ситуацій. 
Запропонована схема є мінімально необхідною, але достатньою для: 
• оперативного доступу до автомобільних записів, 
44 
 
• аналітичної обробки (події, пікові навантаження), 
• контролю користувачів і прав доступу, 
• керування правилами і політиками доступу, 
• надійного журналювання, що важливо для безпеки. 
Модель залишає можливість подальшого розширення, наприклад: 
• додавання білінгу (оплата стоянки), 
• створення модулів для обліку вільних місць, 
• інтеграції з RCS/CRM.  
 REST API є комунікаційним прошарком між ядром ANPR, веб-
інтерфейсом та зовнішніми інформаційними системами (наприклад, Smart 
Parking або мобільними застосунками). API забезпечує як оперативний доступ 
оператора до системи, так і можливість автоматичного керування шлагбаумом 
та перегляду статистики. 
Дизайн REST API побудовано на принципах: 
• чіткої ресурсної моделі, де кожна сутність БД має відповідний endpoint; 
• статeless-взаємодії, що спрощує масштабування; 
• ролевої моделі доступу, що обмежує функції користувачів відповідно до 
їхніх прав; 
• захищеного протоколу HTTPS у виробничому розгортанні. 
API описує не лише операції з даними, а й команди до виконавчих механізмів 
(шлагбаума), що робить його ключовим елементом архітектури. 
Особливості реалізації API: 
1. FastAPI як фреймворк 
Забезпечує автоматичну генерацію документації Swagger/OpenAPI, 
високу продуктивність та асинхронність. 
2. JWT-токени 
Дозволяють відокремити функції ролей (admin, operator, viewer), 
реалізувати time-based expiry та refresh. 
3. Логічне розділення API та ANPR-модуля 
API не виконує OCR чи детекцію — він лише приймає дані та оперує 
45 
 
ними. 
Це відповідає принципу розділення відповідальності. 
4. Сумісність зі Smart Parking 
API може бути інтегровано у більшу систему (міський паркінг, білінг, 
мобільний застосунок). 
5. Резервування та fault-tolerance 
При недоступності бази даних API може працювати в обмеженому 
режимі: перегляд подій з локального кешу, показ станів модулів. 
 Оскільки система контролю доступу на базі ANPR працює у режимі 
реального часу та виконує критичні функції, архітектура повинна гарантувати 
стабільність роботи при часткових або тимчасових збоях. Робастність системи 
полягає у здатності продовжувати функціонувати навіть у разі відмови 
окремих компонентів, а відмовостійкість — у можливості автоматичного 
відновлення роботи після збою. 
Запропонована архітектура містить низку механізмів, розроблених спеціально 
для забезпечення безперервності процесів: 
1. Автоматичне відновлення RTSP-потоку: У випадку втрати відеопотоку 
(нестабільна мережа, перезавантаження камери, недоступність комутатора): 
• виконується стратегія повторних підключень (1, 2, 4, 8 секунд); 
• при довготривалій втраті — система подає сигнал у інтерфейс оператора 
(помітне повідомлення); 
• ANPR-ядро продовжує працювати у режимі очікування без падіння 
процесу. 
Це запобігає зупинці системи внаслідок короткочасних мережевих перебоїв. 
2.Локальний буфер подій при недоступності бази даних: Якщо сервер БД 
тимчасово недоступний (мережа, апдейт, відмова диску), система: 
• записує події у локальний файловий буфер у вигляді черги (.queue); 
• автоматично виконує пакетний перезапис у БД після відновлення 
доступності; 
46 
 
• контролює переповнення буфера: найбільш старі події можуть 
видалятися при перевищенні ліміту. 
Таким чином, історія подій не втрачається, а доступ продовжує працювати. 
3. Повторне OCR при низькій достовірності: Достовірність OCR може 
тимчасово знижуватися через: 
• засвіт з фар, 
• відблиски, 
• швидкість руху, 
• неідеальний нахил номерного знака. 
Для мінімізації помилок використовується: 
• мультикадрове голосування (3–5 кадрів поспіль), 
• алгоритм вибору "найстабільнішого" результату, 
• повторне OCR з альтернативними фільтрами (зміна порогу бінаризації, 
warp). 
Це дозволяє повернути точність OCR до ≥ 95% навіть у складних умовах. 
4. Fail-safe режим при несправності виконавчих механізмів. У разі 
несправності: реле шлагбаума, фотодатчика перешкод, контролера GPIO, 
система переводиться у стан FAILSAFE, при якому: 
• блокуються автоматичні команди відкриття/закриття; 
• шлагбаум переходить у безпечний режим (наприклад, залишається 
відкритим); 
• оператор отримує можливість ручного керування через UI; 
• усі помилки фіксуються у audit_logs. 
Таким чином, зберігається безпека та контроль над системою. 
 Комплекс вбудованих механізмів робастності дозволяє системі 
працювати у промислових умовах, де можливі перебої зв’язку, жорсткі умови 
експлуатації та збої окремих компонентів. Система зберігає працездатність, не 
втрачає дані та мінімізує ризик блокування транспортних потоків. 
47 
 
 Спостережуваність є ключовим аспектом для промислової експлуатації 
ANPR-системи. Без надійного моніторингу та журналювання важко 
забезпечити стабільність, діагностувати проблеми або запобігати інцидентам. 
Архітектура включає структуровані журнали (JSON logging) 
Система фіксує: 
• час події, 
• стан модулів, 
• помилки, 
• рішення Allow/Deny, 
• відладкові параметри (confidence, latency). 
Це дозволяє проводити аналіз інцидентів та будувати автоматизовані правила 
сповіщення. 
 Оскільки система обробляє персональні дані (зображення авто, номери), 
вона повинна відповідати сучасним стандартам інформаційної безпеки. 
Архітектура включає: 
1. TLS/HTTPS для API/UI 
Уникає перехоплення трафіку при авторизації. 
2. Ізольоване зберігання секретів 
Паролі, токени, ключі зберігаються у: 
• .env, 
• менеджерах секретів (Hashicorp, Docker secrets). 
3. Рольова модель доступу (RBAC) 
Ролі: admin, operator, viewer. 
Доступ обмежений лише необхідними функціями. 
4. Політика зберігання фото та логів 
Фото можуть бути видалені через 30–90 днів. 
5. IP-обмеження для адмін-панелі 
6. Адміністративна частина доступна лише з дозволених IP-адрес або VPN. 
 Конфігурація системи централізована і описана у файлі config.yml, де 
зберігаються: 
48 
 
• параметри камер (RTSP URI), 
• пороги YOLO та OCR, 
• шляхи до сховищ, 
• GPIO/HTTP-команди, 
• політики доступу. 
Підтримувані механізми: 
1. Гаряче оновлення списку авто 
Оператори можуть змінювати доступ без перезапуску ядра. 
2. Резервне копіювання БД 
Автоматичні нічні дампи. 
3. Перенесення фото у NAS або хмарне сховище 
Для розвантаження локального диску. 
Запропонована архітектура забезпечує: 
• роботу в реальному часі, 
• локальне прийняття рішень без залежності від хмарних сервісів, 
• високу продуктивність і масштабованість, 
• модульність і ремонтопридатність, 
• надійну безпеку й спостережуваність, 
• стійкість до часткових відмов завдяки fail-safe механізмам, 
• гнучку інтеграцію у Smart Parking або більші системи. 
Таким чином, архітектура є зрілою, промислово орієнтованою та повністю 
готовою до реального розгортання на автостоянках, КПП, логістичних центрах 
та інших об’єктах транспортної інфраструктури. 
 
 2.6. Проєктування бази даних 
 Метою підсистеми даних є надійне зберігання подій ANPR, довідників 
транспортних засобів та користувачів, а також забезпечення швидкого пошуку 
за номером автомобіля та часовими інтервалами. Крім того, база даних 
повинна підтримувати прозоре аудиторське відстеження адміністративних дій 
(додавання/видалення авто, зміна правил доступу тощо). 
49 
 
 Схема БД проєктується для OLTP-навантаження: велика кількість 
коротких транзакцій читання/запису (події в’їзду/виїзду), з можливістю 
подальшого масштабування за рахунок партиціювання таблиць подій та 
рознесення сервісів. 
На концептуальному рівні виділено чотири основні групи сутностей: 
• vehicles — реєстр транспортних засобів (ТЗ), яким може бути наданий 
доступ (у тому числі «гостьові» та «заборонені»); 
• events — журнал подій в’їзду/виїзду з фіксацією номера, часу, рішення, 
фото та метрик; 
• users та audit_logs — підсистема керування користувачами і аудиту 
адміністративних дій; 
• access_rules — таблиця політик доступу (маски номерів, часові вікна, 
тип правила). 
Умовно ER-модель можна подати так: 
• один користувач (users) може бути джерелом багатьох записів у 
audit_logs; 
• один автомобіль (vehicles) може фігурувати у багатьох записах events; 
• events.plate може бути логічно пов’язаний із vehicles.plate (опціональний 
зв’язок, дозволяє логувати «невідомі» номери). 
Це забезпечує: 
• відокремлення довідникових даних (авто, користувачі, правила) від 
потокових подій; 
• можливість розширення моделі (додавання тарифів, сесій, об’єктів 
паркінгу тощо) без радикальної перебудови. 
Логічна модель спроєктована таким чином, що: 
• усі довідники винесені в окремі таблиці; 
• події (events) не дублюють інформацію про власника авто — там 
зберігається лише номер, час, рішення та технічні метрики; 
• інформація про користувачів, їхні ролі та дії із системою зосереджена в 
таблицях users і audit_logs. 
50 
 
Важливим аспектом є нормалізація номерних знаків (plate): 
у таблицях vehicles та events номер зберігається в єдиному канонічному 
форматі: 
• тільки великі літери латиниці/кирилиці та цифри, 
• без пробілів, дефісів та інших символів (наприклад, AA1234BB). 
 Поле plate у events концептуально може мати зовнішній ключ на 
vehicles(plate), але в реальних системах часто від цього відмовляються заради 
продуктивності — події для невідомих номерів (яких немає у vehicles) все одно 
повинні записуватися. Тому референційну цілісність для номерів доцільно 
перевіряти на прикладному рівні або через додаткові ETL-процеси. 
 Зображення зберігаються не у самій БД (хоча це можливо), а у 
файлах/NAS/S3, а в БД фіксується лише шлях або ідентифікатор (image_path). 
Це спрощує резервування, архівацію та масштабування. 
 Для забезпечення цілісності та зручності обробки використовуються 
спеціалізовані типи та домени: 
• plate — VARCHAR(12) (з запасом для форматів номерів, у т.ч. 
іноземних); додатково на рівні застосунку контролюється регулярним 
виразом; 
• direction — перелічуваний тип ENUM('IN','OUT') (у PostgreSQL 
створюється окремим типом direction); 
• decision — ENUM('ALLOW','DENY','MANUAL') — результат рішення 
системи; 
• **conf_det/conf_ocr** — числові типи REALабоNUMERIC(4,3)` у 
діапазоні 0.000–1.000; 
• ts — TIMESTAMPTZ (мітка часу з часовим поясом), що дозволяє 
коректно працювати зі зміщеннями часу; 
• schedule (у access_rules) — JSONB, де можуть зберігатися RRULE/cron-
подібні описання вікон доступу. 
Використання ENUM та CHECK-обмежень забезпечує додаткову захищеність 
від некоректних значень. 
51 
 
 Для систем, де кількість подій може досягати сотень тисяч на добу, 
доцільно застосовувати інтервальне партиціювання таблиці events за полем ts 
(наприклад, по місяцях). 
ALTER TABLE events 
  PARTITION BY RANGE (ts); 
CREATE TABLE events_2025_11 PARTITION OF events 
  FOR VALUES FROM ('2025-11-01') TO ('2025-12-01'); 
Кожного місяця створюється нова партиція. Це дає низку переваг: 
• суттєве прискорення запитів за часовими інтервалами; 
• просте архівування та видалення старих даних (досить відмонтувати 
цілу партицію); 
• розвантаження основного сховища за рахунок перенесення старих 
партицій у «холодне» сховище. 
Для забезпечення одноманітності зберігання номерних знаків застосовується 
тригер нормалізації: 
CREATE OR REPLACE FUNCTION norm_plate() RETURNS TRIGGER AS $$ 
BEGIN 
  NEW.plate := regexp_replace(upper(NEW.plate), '[^A-Z0-9]', '', 'g'); 
  RETURN NEW; 
END; $$ LANGUAGE plpgsql; 
CREATE TRIGGER trg_norm_plate_v BEFORE INSERT OR UPDATE ON vehicles 
FOR EACH ROW EXECUTE FUNCTION norm_plate(); 
CREATE TRIGGER trg_norm_plate_e BEFORE INSERT OR UPDATE ON events 
FOR EACH ROW EXECUTE FUNCTION norm_plate(); 
Це гарантує, що у всіх таблицях номер записаний у єдиному форматі. 
 Додатковий тригер автоматично встановлює причину відмови при 
низькій впевненості OCR: 
CREATE OR REPLACE FUNCTION set_reason_low_conf() RETURNS TRIGGER AS $$ 
BEGIN 
  IF NEW.conf_ocr IS NOT NULL AND NEW.conf_ocr < 0.70 AND NEW.reason IS NULL THEN 
    NEW.reason := 'LOW_OCR_CONF'; 
  END IF; 
  RETURN NEW; 
END; $$ LANGUAGE plpgsql; 
CREATE TRIGGER trg_reason BEFORE INSERT ON events 
FOR EACH ROW EXECUTE FUNCTION set_reason_low_conf(); 
52 
 
Це спрощує подальший аналіз причин відмови системи. 
 Для забезпечення надійності та відповідності вимогам безпеки 
застосовується: 
• політика retention: 
o фото — 60–90 днів (налаштовується), 
o події — 1–3 роки (залежно від вимог замовника); 
• щоденний pg_dump бази даних; 
• щотижнева повна копія сховища зображень; 
• архівування старих партицій таблиці events у «холодне» сховище 
(повільні, але дешеві диски, або glacier-аналог). 
Безпека даних у БД забезпечується комплексно: 
• створення окремого користувача БД anpr_app з мінімальними правами 
(тільки потрібні DML-операції); 
• усі операції DDL/міграцій виконуються від імені адміністраторської ролі 
anpr_admin; 
• обмеження доступу до зображень на рівні API (перевірка ролі, підписані 
URL, обмеження терміну дії посилань); 
• можливе використання механізмів row-level security (RLS) для 
складніших сценаріїв розмежування доступу. 
Запропонована схема бази даних: 
• забезпечує швидкі операції пошуку за номером та часом завдяки 
продуманим індексам та можливості партиціювання; 
• гарантує цілісність та простежуваність даних (audit logs, нормалізація 
номерів, тригери); 
• підтримує масштабованість (партиціювання подій, рознесення сервісів, 
використання NAS/S3); 
• є гнучкою для інтеграції з іншими сервісами через REST API та JSONB-
поля; 
• готова до подальшого розширення функціоналу (тарифи, оплата, мережа 
паркінгів) без радикальної зміни основної структури. 
53 
 
Таким чином, проєктування бази даних повністю відповідає вимогам до 
сучасної ANPR-системи й забезпечує надійну основу для розгортання та 
експлуатації програмно-апаратного комплексу. 
 
 2.7. Алгоритм роботи системи 
 Архітектура обробки побудована у вигляді послідовного конвеєра, де 
кожен модуль виконує окремий етап: 
1. Отримання відеопотоку з IP-камери по RTSP. 
2. Захоплення окремих кадрів із потоку (декодування, буферизація). 
3. Детекція номерної пластини за допомогою YOLO (отримання ROI та 
довірчої оцінки). 
4. Передобробка ROI (перетворення у відтінки сірого, вирівнювання 
контрасту, корекція нахилу, бінаризація). 
5. OCR-розпізнавання символів (Tesseract / CRNN). 
6. Постобробка та валідація (regex, позиційні заміни, мультикадрове 
голосування). 
7. Перевірка в базі даних та застосування політик доступу. 
8. Прийняття рішення Allow/Deny і формування команди на шлагбаум. 
9. Журналювання події з фіксацією фото, метрик та причин. 
 Алгоритм роботи є параметризованим, тобто більшість порогів, 
таймаутів і режимів задаються у конфігураційному файлі (наприклад, 
config.yml). Це дозволяє адаптувати систему без змін вихідного коду. 
 Кожен параметр безпосередньо впливає на поведінку системи: пороги 
conf_thresh та conf_min визначають чутливість до помилок, reconnect_backoff 
— тактику відновлення камери, cache_ttl_s — ефективність кешування рішень, 
а retention_days — політику зберігання зображень. 
 Основний цикл сервісу працює як нескінченний обробник подій, що 
послідовно:захоплює кадри, виконує детекцію, проводить OCR та 
постобробку, звертається до БД і політик доступу, відправляє команду 
шлагбауму, логує події та метрики. 
54 
 
 Для підвищення точності використовується мультикадрове голосування: 
один і той самий номер зчитується кілька разів із послідовних кадрів, а потім 
обирається узгоджений результат. 
Один із варіантів: 
• усі кандидати вирівнюються по довжині; 
• розглядаються лише ті, де довжина збігається з найчастішою (фільтрація 
шуму); 
• далі застосовується алгоритм консенсусу (на основі Левенштейна або 
позиційного голосування). 
Схематичний псевдокод: 
vote(cands): 
  if len(cands) == 0: 
    return None, 0.0 
  L = most_common_length(cands) 
  aligned = [c for c in cands if len(c.text)==L] 
  if len(aligned) == 0: 
    aligned = cands 
  best = consensus_levenshtein(aligned, top_k=3) 
  conf = mean([c.conf for c in aligned if c.text==best]) or max_conf(aligned) 
  return best, conf 
Такий підхід дозволяє згладити випадкові OCR-помилки та отримати 
стабільний результат. 
Після отримання «сирого» тексту від OCR виконується постобробка: 
1. Нормалізація: 
upper(), видалення пробілів, дефісів, неалфанумеричних символів. 
2. Позиційні заміни символів, враховуючи формат номерного знака: 
o у буквених позиціях: 0→O, 1→I, 8→B, 2→Z, 
o у цифрових позиціях: O→0, I→1, B→8, Z→2. 
3. Regex-валідація для українського формату: 
^[ABCEHIKMOPTX]{2}\d{4}[ABCEHIKMOPTX]{2}$. 
4. Якщо номер не проходить валідацію, виконується альтернативна 
передобробка (інші параметри бінаризації, контрасту) та повтор OCR. 
55 
 
Якщо після цього валідація все одно не успішна — подія вважається 
LOW_CONF, а рішення за замовчуванням — Deny. 
Модуль політик (policy engine) формалізує логіку Allow/Deny: 
1. Якщо номер знайдено у кеші останніх рішень (TTL, наприклад 60 с) — 
рішення береться з кешу. 
2. Якщо номер присутній у таблиці vehicles зі статусом active — рішення 
ALLOW. 
3. Якщо існує одна чи кілька відповідних політик у access_rules (маски, 
розклади, пріоритети) — застосовується правило з найвищим 
пріоритетом. 
4. Якщо номер не знайдено і правила не допускають allow — рішення 
DENY. 
Такий механізм дозволяє реалізувати як прості «білі списки», так і складні 
сценарії по часових вікнах. 
 Кожна подія в’їзду/виїзду записується у БД у вигляді структурованого 
запису, який містить: 
• ts — час події, 
• plate — нормалізований номер (або NULL при невдачі OCR), 
• direction — напрямок руху (IN/OUT), 
• decision — результат (ALLOW/DENY/MANUAL), 
• conf_det, conf_ocr — довірчі оцінки, 
• image_path — шлях до збереженого зображення, 
• reason — причина для DENY або спеціальних станів (наприклад, 
LOW_CONF, NO_MATCH, BARRIER_FAIL). 
 Важливим є атомарний характер операції: спочатку зберігається фото (у 
файловій системі/NAS/S3), потім у транзакції БД фіксується запис з 
image_path. Якщо з якоїсь причини збереження фото не вдалося, у події 
фіксується відповідна причина (IMAGE_STORE_FAIL). 
 Керування шлагбаумом реалізується як машина станів, яка реагує на 
рішення ANPR-модуля, сигнали датчиків та таймери. 
56 
 
Стислий псевдокод: 
barrier_open(): 
  if state in {OPEN, OPENING}: 
    return True 
  set_state(OPENING) 
  if relay_on():                      # GPIO/HTTP/RS485 
    if wait_until(photo_beam_clear, t=open_timeout_s): 
      set_state(OPEN) 
      start_timer(close_timeout_s) 
      return True 
  set_state(FAILSAFE) 
  return False 
on_timer_close(): 
  if safety_sensor_blocked(): 
    defer_close() 
  else: 
    relay_off() 
    set_state(CLOSING) 
    if wait_until(end_switch_closed, t=close_timeout_s): 
      set_state(IDLE_CLOSED) 
    else: 
      set_state(FAILSAFE); alert_operator() 
 Додатково реалізується anti-tailgating: якщо під час спроби закриття 
фотодатчик фіксує авто, закриття відкладається до звільнення зони. 
Для кожного типу збою система має передбачену реакцію: 
• Втрата RTSP-потоку: експоненційний backoff (1, 2, 4, 8, 16 с), 
відображення стану CAMERA_DOWN у UI, автоматична спроба 
підключення. 
• Помилки OCR: повторне зчитування з альтернативною передобробкою, 
використання мультикадрового голосування. 
• Перевищення часу відкриття/закриття шлагбаума: переведення системи 
у FAILSAFE з вимогою ручного втручання. 
• Недоступність БД: накопичення подій у локальному файловому буфері 
.queue з подальшим flush при відновленні. 
• Перевантаження CPU/системи: пропуск частини кадрів (обробка 
кожного k-го кадру) з пріоритетом детекція → OCR → рішення. 
57 
 
• Нестача місця для фото: автоматична ротація старих знімків відповідно 
до retention_days і попередження оператора. 
Щоб забезпечити роботу в реальному часі, конвеєр реалізований як набір 
воркерів, з’єднаних чергами: 
• capture → detect → ocr → postproc → decision → io/log. 
Застосовуються: 
• back-pressure: якщо OCR не встигає, зменшується частота кадрів, що 
подаються на OCR; 
• zero-copy: між модулями передаються посилання на буфери кадрів, а не 
їх копії; 
• кешування рішень (LRU), що знижує навантаження на БД при повторних 
проїздах. 
Для верифікації алгоритму визначено типові сценарії: 
1. Базовий Allow: номер присутній у БД, conf_ocr ≥ 0.9, час від появи авто 
до відкриття шлагбаума ≤ 2 с. 
2. Deny по no-match: номер розпізнано коректно, але його немає у vehicles. 
3. Low Conf: conf_ocr < 0.7, повторні спроби зчитування не дають валідного 
regex → DENY + LOW_CONF. 
4. Edge case (O/0, I/1, B/8): перевірка роботи позиційних замін та regex. 
5. RTSP down: симуляція недоступності камери та подальшого 
відновлення. 
6. Barrier fault: апаратна відмова кінцевика шлагбаума → FAILSAFE. 
7. Mass flow / tailgating: два авто поспіль, перевірка anti-tailgating логіки. 
Блок-схему можна формально описати як послідовність: 
1. Старт сервісу, ініціалізація модулів. 
2. Захоплення кадру. 
3. Якщо номера не знайдено — перехід до наступного кадру. 
4. Якщо номер знайдено — передобробка + OCR. 
5. Якщо LOW_CONF — спроба повторного зчитування, у разі невдачі — 
DENY. 
58 
 
6. Якщо номер валідний — запит у БД, застосування політик. 
7. При ALLOW — команда open() шлагбауму, логування. 
8. При DENY/UNCERTAIN — тільки логування та інформування оператора. 
9. Повернення до наступного кадру. 
 Для забезпечення комфортного користування системою вводяться 
цільові часові характеристики: 
• T₁ (детекція, YOLO + ROI): ≤ 100–200 мс; 
• T₂ (передобробка + OCR): ≤ 150–300 мс; 
• T₃ (доступ до БД + рішення + команда шлагбауму): ≤ 100–300 мс; 
• Σ (end-to-end, від появи авто до команди на шлагбаум): 
– граничне значення: ≤ 3 с. 
 Розроблений алгоритм роботи системи описує повний життєвий цикл 
події ANPR — від надходження відеопотоку до фізичного керування 
шлагбаумом і внесення запису до журналу подій. Враховано: різні варіанти 
помилок, механізми підвищення точності (мультикадрове голосування, 
постобробка), політики доступу та кешування, управління виконавчими 
механізмами, вимоги до продуктивності та часових характеристик. 
 Це забезпечує досягнення необхідної точності розпізнавання (≥ 95 %) та 
затримки (≤ 2–3 с), що відповідає вимогам реального часу для автоматизованих 
систем контролю доступу на автостоянках. 
 
 2.8. Висновки до розділу 2 
 У другому розділі було виконано комплексне проєктування системи 
автоматизованого доступу та обліку автомобілів на автостоянці на основі 
технології розпізнавання номерних знаків (ANPR). У ході цього проєктування 
послідовно сформовано структуру майбутньої системи, визначено її 
функціональні можливості, вимоги та обмеження, побудовано архітектуру, 
описано алгоритми роботи та спроєктовано модель даних, необхідну для 
надійного зберігання інформації. 
59 
 
 Насамперед була сформульована постановка задачі. Визначено, що 
основною метою системи є автоматизація доступу транспортних засобів на 
територію автостоянки без постійної участі оператора, причому ідентифікація 
автомобіля здійснюється за державним реєстраційним номерним знаком. 
Система повинна забезпечувати керування шлагбаумом, облік подій в’їзду та 
виїзду транспортних засобів, а також функціонування в режимі реального часу, 
що накладає жорсткі вимоги до затримок обробки та стабільності роботи. 
 Далі, були визначені функціональні вимоги до системи. Сформовано 
набір обов’язкових функцій: захоплення відеопотоку з IP-камери, детекція 
області номерного знака, розпізнавання символів за допомогою OCR, 
перевірка розпізнаного номера в базі даних, автоматичне відкриття шлагбаума 
за умови позитивного рішення, ведення журналу усіх подій в’їзду/виїзду та 
надання зручного веб-інтерфейсу для адміністратора й оператора. Таким 
чином, було чітко окреслено функціональну рамку системи. 
 У підрозділі 2.3 сформульовано нефункціональні вимоги та обмеження, 
що задають цільові показники якості. Було встановлено, що точність 
розпізнавання номерних знаків має перевищувати 95 %, а час прийняття 
рішення щодо доступу не повинен перевищувати приблизно двох секунд. 
Окремо наголошено на необхідності безперервної роботи в режимі 24/7, 
можливості масштабування до декількох камер і контрольних пунктів 
пропуску, а також наявності механізмів відмовостійкості: автоматичного 
перепідключення до камери, буферизації подій у разі недоступності бази 
даних, переходу шлагбаума до безпечного (fail-safe) режиму при збоях 
виконавчих механізмів. 
 Для реалізації ANPR-модуля запропоновано використання IP-камер із 
ІЧ-підсвіткою та режимом «день/ніч», обчислювального вузла на базі MiniPC 
або NVIDIA Jetson, а також релейного або цифрового модуля для керування 
шлагбаумом. Показано, що така конфігурація дозволяє виконувати всю 
обробку локально, без залежності від хмарних сервісів і дорогих ліцензійних 
рішень, забезпечуючи прийнятний баланс між вартістю та продуктивністю. 
60 
 
  Запропоновано модульну edge-архітектуру, у межах якої всі критичні 
рішення щодо надання або заборони доступу приймаються локально на ANPR-
вузлі. Описано логічне розділення на модулі захоплення відео, детекції, 
передобробки, OCR, постобробки, прийняття рішень, керування шлагбаумом, 
роботи з базою даних та надання веб-інтерфейсу. Розглянуто варіанти 
розгортання системи — від одного КПП із локальною БД до конфігурацій з 
кількома контрольними пунктами і центральною базою даних, а також 
сценарій інтеграції до концепції Smart Parking. Такий підхід забезпечує 
модульність, розширюваність та зручність подальшого супроводу. 
 Побудовано концептуальну ER-модель та логічну схему БД. Показано, 
що така структура дозволяє ефективно зберігати інформацію про транспортні 
засоби, події в’їзду/виїзду, користувачів системи та адміністративні дії, а також 
задавати гнучкі політики доступу. Окрему увагу приділено індексуванню, 
нормалізації, можливості партиціювання таблиці подій за часом та реалізації 
аудит-трейлу для забезпечення простежуваності змін і конфіденційності 
даних. 
 Розроблено детальний алгоритм роботи системи. Описано повний 
конвеєр розпізнавання — від детекції номерного знака нейронною мережею 
(YOLO), через OCR-розпізнавання символів, до постобробки результатів, 
застосування правил доступу, формування команд для шлагбаума та логування 
подій. Особливо підкреслено використання мультикадрового голосування для 
підвищення точності, механізмів виправлення типових OCR-помилок, 
кешування рішень для зменшення затримок та обробки помилкових ситуацій 
із переходом до fail-safe сценаріїв. 
 Повністю визначено логіку роботи та внутрішню структуру системи, яка 
розробляється. На основі проведеного аналізу й проєктних рішень створено 
міцний фундамент для практичної реалізації програмно-апаратного 
комплексу: від вибору обладнання та побудови архітектури до формалізації 
алгоритмів і структури бази даних. Обрані технічні підходи дозволяють 
забезпечити високу точність розпізнавання номерних знаків, роботу в режимі 
61 
 
реального часу з мінімальним втручанням персоналу, масштабованість до 
декількох контрольних пунктів або цілої мережі стоянок, а також необхідний 
рівень відмовостійкості та захисту даних. Запроєктована система має суттєвий 
потенціал подальшого розвитку: вона може бути доповнена модулями 
тарифікації та оплати, мобільним застосунком для користувачів, а також 
інтегрована до міських систем розумного паркування (Smart Parking), що 
розширює сферу її практичного застосування. 
62 
 
РОЗДІЛ 3. РОЗРОБЛЕННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ТА 
АЛГОРИТМУ РОЗПІЗНАННЯ НОМЕРНИХ ЗНАКІВ 
 3.1. Загальна структура програмного забезпечення 
 Програмне забезпечення розробленої системи автоматизованого доступу 
та обліку автомобілів на автостоянці побудовано за модульною архітектурою, 
яка забезпечує чіткий розподіл відповідальностей між різними частинами 
комплексу. Поділ на окремі модулі дає можливість незалежно виконувати 
обробку відеопотоку, застосовувати алгоритми комп’ютерного зору, 
реалізовувати логіку прийняття рішень щодо доступу, керувати виконавчими 
механізмами та взаємодіяти з базою даних. Такий підхід підвищує надійність 
роботи системи, спрощує масштабу-вання, полегшує тестування й дозволяє 
легко модернізувати окремі компоненти без втручання в роботу всієї 
інфраструктури. 
 Логічна структура програмного забезпечення охоплює кілька тісно 
пов’язаних між собою підсистем. Центральне місце займає модуль ANPR, 
який відповідає за детекцію номерного знака за допомогою нейронної мережі 
YOLO та подальше розпізнавання символів за допомогою OCR-двигуна 
(Tesseract або CRNN). Цей модуль функціонує як точка входу для всього 
конвеєра обробки зображень: він приймає RTSP-потік від IP-камери, виділяє 
ROI номерної пластини та формує нормалізований текстовий результат. Якість 
та швидкість його роботи визначають загальну продуктивність системи. 
 Другим важливим компонентом є підсистема доступу, яка виконує логіку 
перевірки номерного знака у базі даних, співставлення зі списками дозволених 
транспортних засобів або політиками доступу, формування рішення Allow або 
Deny та передавання його до модуля керування шлагбаумом. Саме тут 
реалізується бізнес-логіка системи: визначаються правила доступу, 
обробляються граничні випадки та перевіряються часові розклади, маски 
номерів і статуси транспортних засобів. 
 Модуль керування шлагбаумом виконує функції взаємодії з обладнанням 
через GPIO, USB-реле або HTTP-інтерфейс. Його завдання — забезпечити 
63 
 
фізичне відкриття та закриття шлагбаума згідно з отриманими командами, 
контролювати кінцеві вимикачі, фотоелементи та інші датчики, а також 
переводити механізм у fail-safe режим у разі несправностей або перевищення 
допустимого часу роботи. Завдяки реалізації машини станів забезпечується 
коректна взаємодія з обладнанням навіть у складних сценаріях (наприклад, 
«anti-tailgating», виявлення перешкод, повторне відкриття тощо). 
 Ще одним великим блоком є веб-інтерфейс та REST API. Цей модуль 
забезпечує доступ операторів і адміністраторів до системи, подання журналу 
подій, керування реєстром транспортних засобів, аналіз статистики, ручне 
керування шлагбаумом, а також перегляд діагностичної інформації. REST API 
слугує універсальним каналом зв’язку між підсистемами, забезпечуючи 
стандартизований формат обміну даними та інтеграцію із зовнішніми 
сервісами. Завдяки цьому можлива інтеграція системи в більші 
інфраструктурні рішення, такі як міські Smart Parking-платформи або білінгові 
модулі. 
 Фізично програмне забезпечення організовано у вигляді чіткої структури 
каталогів, де кожен модуль розміщено в окремій директорії. Ядро ANPR 
містить модулі для детекції, OCR, передобробки та побудови конвеєра. 
Підсистема доступу представлена файлами, що реалізують політику доступу 
та взаємодію з базою даних. Модуль керування шлагбаумом включає драйвери 
GPIO та логіку станів. Веб-модуль містить REST API, елементи авторизації та 
графічний інтерфейс. Окремо розміщено SQL-схеми, конфігураційні файли та 
системні логи. 
 Життєвий цикл кожної події у системі включає кілька етапів. Спочатку 
IP-камера передає потік у модуль ANPR, який визначає номерну пластину та 
розпізнає текст. Потім підсистема доступу перевіряє цей номер у базі даних і 
приймає рішення щодо дозволу або заборони доступу. Рішення передається до 
підсистеми керування шлагбаумом, яка фізично відкриває або не відкриває 
механізм. Наприкінці подія фіксується в базі даних разом із зображенням та 
64 
 
службовою інформацією для подальшого аналізу. Усі ці операції відбуваються 
в межах кількох секунд, що відповідає вимогам режиму реального часу. 
 Модулі взаємодіють між собою через внутрішні REST-виклики, черги 
подій та уніфіковані механізми логування. Таке рішення дозволяє організувати 
систему в умовно мікросервісному стилі, забезпечити відмовостійкість і 
значно спростити масштабування. Можна розширювати можливості системи, 
додаючи нові камери, додаткові ANPR-вузли або центральний сервер без 
суттєвих змін у програмній логіці. 
 У підсумку структура програмного забезпечення є гнучкою, 
масштабованою і орієнтованою на реальні умови експлуатації автостоянки. 
Вона забезпечує можливість подальшого розвитку системи, включно з 
інтеграцією нових алгоритмів комп’ютерного зору, додаванням додаткових 
модулів аналітики, переходом від локальної бази даних до розподілених 
сервісів або інтеграцією з міськими інтелектуальними інфраструктурами. 
 
 3.2. Технологічний стек 
 Технологічний стек системи автоматизованого доступу та обліку 
автомобілів на основі ANPR формувався з урахуванням вимог до 
стабільності, надійності роботи, можливості обробки відеопотоку в 
реальному часі та сумісності з апаратними платформами, які 
використовуються у системах автоматизованого контролю доступу. 
Важливим критерієм була також наявність потужних інструментів 
комп’ютерного зору й машинного навчання, здатних забезпечити високу 
точність розпізнавання номерних знаків. Усі обрані компоненти 
технологічного стеку мають відкриту ліцензійну модель або можуть 
застосовуватись без додаткових роялті, що унеможливлює залежність від 
окремих виробників та дозволяє розгортати систему на будь-якому 
обладнанні. 
 Основною мовою програмування, використаною під час розробки 
системи, став Python 3.x. Його застосовано для реалізації ключових модулів, 
65 
 
зокрема ядра ANPR, алгоритмів детекції та OCR, логіки доступу, REST API 
та інтеграції з базою даних. Python був обраний через його універсальність, 
широкий спектр бібліотек комп’ютерного зору (наприклад, OpenCV), 
машинного навчання (PyTorch) і розпізнавання тексту (Tesseract), а також 
швидкий цикл розробки, що є важливим у проєктах такого типу. Для 
реалізації веб-інтерфейсу адміністратора та оператора було застосовано 
JavaScript сучасного стандарту ES6+, який дозволяє створювати інтерактивні 
та динамічні вебсторінки. Мова SQL використовувалася для створення схеми 
бази даних, написання транзакційних запитів та реалізації тригерів у SQLite 
або PostgreSQL — залежно від конфігурації розгортання. 
 Ключові бібліотеки та фреймворки, що використовувались у системі, 
також були підібрані відповідно до завдань ANPR. Для обробки відео, 
декодування RTSP-потоку, передобробки зображень та трансформацій ROI 
було застосовано бібліотеку OpenCV, яка є стандартом де-факто у сфері 
комп’ютерного зору. Детекцію номерних знаків забезпечує нейронна мережа 
YOLO — у роботі використано реалізації на базі фреймворку PyTorch, 
зокрема моделі YOLOv5 або YOLOv8 від команди Ultralytics. Ці моделі 
демонструють високу швидкість та точність, що робить їх оптимальними для 
роботи в режимі реального часу. Для OCR-розпізнавання було обрано 
Tesseract OCR або нейромережевий підхід на базі CRNN (EasyOCR), залежно 
від потрібної швидкодії та якості на конкретному обладнанні. 
 Серверну частину, що відповідає за REST API, авторизацію, обробку 
запитів веб-інтерфейсу та інтеграцію між внутрішніми модулями, реалізовано 
за допомогою фреймворків Flask або FastAPI. Обидва варіанти забезпечують 
високу продуктивність, простоту конфігурації та можливість швидкого 
розширення функціоналу. Для взаємодії з базою даних використовувався 
ORM-рівень SQLAlchemy, який дозволяє працювати з таблицями у вигляді 
Python-об’єктів і одночасно виконувати оптимізовані SQL-запити в 
автоматичному режимі. 
66 
 
 Система зберігання даних ґрунтується на двох можливих рішеннях. Для 
компактних розгортань із одним КПП застосовувалась база SQLite, яка не 
вимагає встановлення окремого серверного програмного забезпечення. Для 
масштабних систем із кількома камерами або кількома контрольними 
пунктами використовувалась PostgreSQL, що забезпечує високу 
продуктивність, підтримку індексів, партиціювання таблиць, реплікацію та 
розширені механізми безпеки даних. Таким чином, архітектура системи 
дозволяє працювати як у легковажному (lightweight) режимі, так і в 
промисловому середовищі. 
 На фронтенді веб-інтерфейсу застосовано стандартні технології 
HTML5, CSS3 та JavaScript, доповнені Bootstrap для стилізації, DataTables.js 
для зручної роботи з журналами подій та REST-клієнтами Axios чи Fetch API 
для взаємодії з сервером. За потреби інтерфейс може бути розширено за 
допомогою React.js, що забезпечить вищу інтерактивність та кращу 
масштабованість UI. 
 Особлива увага була приділена взаємодії програмного забезпечення з 
апаратною частиною системи. IP-камери передають відеопотік протоколом 
RTSP, що є стандартом для відеоспостереження та підтримується більшістю 
моделей. Керування шлагбаумом реалізовано через GPIO або USB-реле, а 
також за допомогою HTTP API для контролерів, які підтримують мережеві 
команди. Аппаратною платформою слугує або компактний MiniPC, або 
спеціалізований модуль NVIDIA Jetson Nano / Xavier, який забезпечує 
апаратне прискорення CUDA для роботи нейронних мереж. 
 Інструменти розробки включали середовища Visual Studio Code та 
PyCharm, систему контролю версій Git разом із репозитаріями GitHub або 
GitLab, а також Postman і Swagger UI для інтеграційного тестування REST 
API. У разі потреби система може бути контейнеризована за допомогою 
Docker, що значно спрощує розгортання та масштабування. 
 Схема технологічного рішення побудована послідовно: потік з IP-
камери надходить до YOLO-детектора, де формується ROI; потім передається 
67 
 
до модуля OCR; результат розпізнавання опрацьовується модулем Access 
Controller; шлагбаум відкривається через реле або GPIO; подія фіксується у 
базі даних; а оператор отримує відповідну інформацію через веб-інтерфейс. 
Така архітектура реалізує принцип edge-first, тобто всі критичні обчислення 
виконуються безпосередньо на вузлі, незалежно від доступності зовнішніх 
сервісів. 
 У підсумку обраний технологічний стек повністю відповідає вимогам 
до систем автоматизованого доступу на основі ANPR. Він забезпечує 
гнучкість, модульність, високу продуктивність, можливість роботи в режимі 
реального часу та сумісність з недорогими апаратними платформами, 
зберігаючи при цьому відкритість, відсутність прив’язки до конкретних 
виробників і потенціал для подальшого розвитку. 
 
 3.3. Алгоритм детекції та виділення номерного знаку (YOLO) 
 У системі автоматичного розпізнавання номерних знаків першим і 
ключовим етапом є коректне визначення області, в якій розташована номерна 
пластина автомобіля. Саме від точності виділення ROI (Region of Interest) 
залежить результат OCR, швидкість обробки та загальна надійність роботи 
системи. Для розв’язання цієї задачі використовується нейронна мережа 
YOLO (You Only Look Once), що є одним із найефективніших алгоритмів 
одностадійної детекції об’єктів у реальному часі. 
 YOLO відрізняється від класичних алгоритмів багатостадійної детекції 
тим, що аналізує все зображення за один прохід через мережу, що суттєво 
скорочує затримку між отриманням кадру та видачею результату. Алгоритм 
безпосередньо прогнозує координати прямокутників, у яких можуть міститися 
об’єкти, а також визначає ймовірність їх належності до певного класу. Для 
номерних знаків це дає змогу точно й швидко локалізувати пластину навіть в 
умовах руху, змін освітлення чи часткового перекриття. На виході YOLO 
формує набір детекцій, кожна з яких містить координати прямокутної області, 
розмір, центр, значення довірчості та ідентифікатор класу. Саме ця 
68 
 
одностадійність дозволяє системі працювати на компактних обчислювальних 
пристроях, таких як MiniPC або NVIDIA Jetson. 
 Після отримання чергового кадру з відеопотоку RTSP він 
перетворюється у формат, придатний для подачі в нейромережу: виконується 
масштабування до потрібного розміру (наприклад, 640×640), нормалізація та 
формування тензора. YOLO аналізує кадр і повертає набір можливих областей, 
де, на думку моделі, розташована номерна пластина. Далі відбувається 
фільтрація за рівнем довірчості — залишаються лише ті прямокутники, у яких 
значення confidence перевищує заданий поріг (зазвичай 0.35–0.60). Після цього 
застосовується алгоритм Non-Maximum Suppression (NMS), який усуває 
дублікати та перекриття: якщо кілька прямокутників описують один і той 
самий номер, залишається лише найточніший. Результатом цього етапу є точне 
визначення координат ROI на зображенні. 
 Архітектурно модель складається з трьох основних частин. Спочатку 
Backbone виділяє високорівневі ознаки з вхідного зображення та формує 
представлення, яке містить значущу інформацію щодо структури сцени. Потім 
Neck поєднує ознаки різного масштабу, що дозволяє успішно детектувати 
номерні знаки як великих, так і малих розмірів, незалежно від перспективи чи 
відстані. Завершальним блоком є Head, що генерує набір прямокутників і 
визначає для кожного з них ступінь впевненості. Така побудова мережі 
дозволяє YOLO демонструвати високу точність та швидкість, необхідні для 
задачі ANPR. 
 Після виділення ROI цей фрагмент кадру піддається спеціальній 
передобробці, що підвищує якість подальшого OCR. Спочатку зображення 
переводиться у відтінки сірого, що спрощує аналіз символів. Потім 
виконується покращення контрасту за допомогою адаптивного вирівнювання 
гістограми (CLAHE), а також виправлення перекосу пластини (deskew), що є 
важливим у разі, коли камера встановлена під нахилом або автомобіль 
рухається під кутом до площини зйомки. Завершальним етапом є бінаризація 
— перетворення зображення у чорно-білий формат, оптимальний для роботи 
69 
 
OCR. Саме ця передобробка забезпечує стабільність розпізнавання навіть у 
складних умовах. 
 YOLO може повертати декілька можливих областей номерних знаків. 
Остаточний вибір виконується за допомогою NMS, який порівнює перекриття 
прямокутників і обирає найбільш достовірний варіант. Для цього 
використовується метрика IoU (Intersection over Union), зазвичай у межах 0.4–
0.5. Завдяки цьому в системі не виникають дублікати одного й того ж 
номерного знака, що дозволяє уникати помилок при подальшому OCR. У 
реальних умовах система може виявляти кілька номерів у кадрі — наприклад, 
на парковці або біля шлагбаума, коли зупиняються кілька автомобілів. У таких 
випадках всі валідні ROI передаються на обробку. 
 У програмному забезпеченні використовується модель YOLO, 
натренована на вибірці номерних знаків. Після завантаження моделі виклик 
детектора над кадром повертає список прямокутників, які містять координати 
області номерної пластини та рівень довірчості. На їх основі формується ROI, 
яке передається на наступні етапи конвеєра ANPR. 
 Серед усіх доступних методів детекції YOLO забезпечує найкращий 
баланс між точністю й швидкодією. На відміну від класичних детекторів, як-
от Haar Cascades, YOLO працює стабільно в умовах руху, змін освітлення та 
шумів. У порівнянні з двостадійними моделями (SSD, Faster R-CNN) YOLO 
демонструє більшу швидкість, що є критичним для систем, які повинні 
реагувати на події в режимі реального часу. Актуальні версії YOLO (YOLOv8) 
забезпечують локалізацію номерного знаку з точністю до 97–99% та 
продуктивність до 30 FPS навіть на обмежених апаратних платформах. 
 Таким чином, застосування YOLO у модулі детекції номерних пластин 
дозволяє досягти високої точності та швидкості локалізації, що є необхідною 
умовою для роботи системи ANPR. Однопрохідна архітектура моделі, 
ефективна обробка кадру, механізми NMS та стійкість до різних умов зйомки 
роблять YOLO оптимальним інструментом для побудови надійної та 
продуктивної системи автоматизованого доступу. 
70 
 
 3.4. Передобробка зображення перед OCR 
 Передобробка зображення виконує ключову роль у конвеєрі ANPR, 
оскільки саме від якості вхідного фрагмента номерної пластини залежить 
точність роботи OCR-модуля. Хоч YOLO забезпечує точне позиціонування 
області номерного знака, виділений ROI часто містить значну кількість 
оптичних дефектів — відблиски фар, різкі контрастні переходи, зернистість 
нічної зйомки, нечіткі контури через рух або викривлення перспективи. Усі ці 
фактори суттєво ускладнюють розпізнавання символів. Тому між етапами 
детекції та OCR вводиться спеціальний каскад фільтрів і геометричних 
перетворень, призначений для отримання максимально чітких, контрастних і 
рівних зображень символів. 
 Першим етапом обробки ROI є перетворення його у градації сірого, що 
дає змогу усунути надлишкову інформацію кольорових каналів та зменшити 
загальний рівень шуму. Далі застосовується адаптивне вирівнювання 
гістограми CLAHE, яке не лише підвищує локальний контраст, але й запобігає 
перенасиченню світлих ділянок, характерних для номерів з відбитим 
інфрачервоним світлом. На відміну від класичного equalizeHist, CLAHE 
працює блочно, що дозволяє вирівнювати контраст навіть на сильно 
нерівномірно освітлених пластинах. 
 Наступною важливою процедурою є усунення нахилу або 
перспективного викривлення. Оскільки bounding box, який повертає YOLO, є 
прямокутником, орієнтованим паралельно осям кадру, реальна номерна 
пластина в межах цього прямокутника може бути нахилена. Для усунення 
цього ефекту застосовується метод cv2.minAreaRect, який дозволяє визначити 
найбільш ймовірний кут нахилу, після чого ROI повертається на відповідний 
кут. У випадках, коли номерний знак був знятий під гострим кутом (наприклад, 
camera-off-axis), може застосовуватись перспективна трансформація на основі 
пошуку кутових точок прямокутника. 
 Після геометричного вирівнювання зображення піддається фільтрації 
шуму за допомогою медіанного або гаусового фільтра. Медіанне згладжування 
71 
 
є особливо ефективним при роботі з дрібними зернистими шумами, які 
виникають під час нічної зйомки або при низькій якості камери. Це дозволяє 
зменшити кількість артефактів, які OCR може помилково сприймати як 
символи або їх частини. 
 Ключовим етапом у підготовці зображення до OCR є бінаризація — 
перетворення у чорно-білий формат. Найкращий результат у більшості умов 
забезпечує адаптивне порогування, яке локально обирає поріг для кожного 
фрагмента зображення і добре працює в умовах нерівномірного освітлення. 
Коли контраст між символами і фоном однорідний, застосовується метод Оцу, 
який автоматично підбирає оптимальний глобальний поріг. На цьому етапі 
зображення фактично приводиться до форми, яка найбільш наближена до 
друкованого тексту — світле тло та темні символи. 
 Завершальною фазою є морфологічна очистка результату, де за 
допомогою операцій відкриття (MORPH_OPEN) видаляються дрібні точки та 
артефакти, що не належать до символів. Зайві контури, піксельні «острівці» 
або залишкові шуми можуть призвести до помилкових спрацьовувань OCR, 
тому їх усунення є необхідним для отримання стабільного результату. 
 Підсумовуючи, передобробка перетворює фрагмент номерної пластини 
із шумного, нерівномірно освітленого, інколи викривленого кольорового 
зображення у чіткий бінарний образ, оптимізований для подальшого 
розпізнавання. Практичні вимірювання показують, що без передобробки 
точність OCR для номерних знаків може перебувати в межах 65–75 %, тоді як 
застосування CLAHE, deskew, фільтрації та адаптивної бінаризації піднімає 
цей показник до 92–97 %, що значно зменшує кількість false-negative та false-
positive результатів. 
 Передобробка зображення є критичним етапом у системах ANPR і 
визначає успішність подальшого розпізнавання. Використання комбінованих 
методів покращення контрасту, вирівнювання геометрії та очищення 
зображення забезпечує оптимальні умови для OCR-модуля, значно підвищує 
72 
 
точність розпізнавання і робить систему стійкою до реальних умов 
експлуатації — від нічної зйомки до складних погодних та оптичних сценаріїв. 
 
 3.5. Розпізнавання символів номерного знаку (OCR) 
 Етап розпізнавання символів є центральною ланкою системи ANPR, 
оскільки саме він перетворює підготовлений фрагмент номерної пластини у 
машинний текст, який надалі використовується для ухвалення рішення щодо 
доступу. Після того як YOLO визначає положення номерного знаку, а модуль 
передобробки формує чітке та контрастне зображення, система передає цей 
фрагмент у OCR-движок. Метою OCR є виділення окремих символів, аналіз 
їхніх форм і формування текстового рядка, що відповідає державному 
реєстраційному номеру транспортного засобу. 
 Загальна логіка роботи OCR у системі ANPR полягає у послідовному 
проходженні кількох етапів: отримання бінаризованого ROI, аналізу 
структурних елементів зображення, розпізнавання символів за допомогою 
моделі, нормалізації отриманого тексту та оцінювання впевненості результату. 
Важливо розуміти, що навіть досконала детекція номерної пластини не 
гарантує коректного розпізнавання, якщо OCR не здатний обробити шум, 
спотворення чи нестандартні символи. Саме тому у системі використовується 
комбінація ретельної передобробки та коригування результатів після OCR. 
 У проєкті передбачено можливість застосування двох OCR-підходів — 
класичного Tesseract OCR з LSTM-ядром та більш сучасної нейронної моделі 
CRNN. Мережа CRNN забезпечує найвищу точність навіть на складних 
зображеннях та не потребує попереднього сегментування символів, проте має 
вищі вимоги до ресурсів і найкраще працює із підтримкою GPU. Для 
кваліфікаційного проєкту раціонально обрано Tesseract, оскільки він вільно 
розповсюджується, легко інтегрується в Python-середовище та забезпечує 
достатню точність для стандартних українських номерних знаків за умови 
якісної передобробки. 
73 
 
 Tesseract використовує параметри конфігурації, оптимізовані саме під 
завдання розпізнавання номерів. Зокрема, режим PSM 7 наказує моделі 
інтерпретувати вхід як один рядок тексту, що відповідає формату розміщення 
символів на номерній пластині. Крім того, за допомогою whitelist виконується 
обмеження множини допустимих символів — до українського набору літер та 
арабських цифр. Це суттєво зменшує кількість хибних визначень, адже 
забороняє появу символів, яких фізично не може бути на державному номері. 
Завдяки цьому OCR отримує не просто зображення тексту, а суворо 
структурований вхід. 
 У момент розпізнавання Tesseract повертає текстовий рядок та числові 
оцінки впевненості для кожного сегмента. Система усереднює їх і формує 
загальний confidence score. Якщо цей показник є нижчим певного порогу 
(наприклад, 0.70), модуль ANPR виконує повторну спробу розпізнавання — 
уже з альтернативною схемою бінаризації або з поширеними параметрами 
фільтрації. Такий механізм повторних спроб дозволяє компенсувати складні 
умови зйомки: тіні, шум, відблиски чи часткову розмитість. 
 Після отримання первинного тексту система виконує постобробку. 
Найважливішим її елементом є нормалізація символів, оскільки OCR часто 
плутає схожі форми: «0» і «О», «1» і «І», «8» і «В», «2» і «Z». Після 
нормалізації застосовується регулярний вираз, що відповідає формату 
українських номерів — дві літери, чотири цифри, дві літери. Якщо результат 
не проходить цю перевірку, система намагається скоригувати окремі символи 
або повертає статус невпевненого розпізнавання. 
 Для досягнення максимальної точності в реальних умовах 
застосовується мультикадрове голосування. Замість того, щоб покладатися на 
один кадр, система аналізує декілька послідовних ROI і порівнює результати. 
У більшості випадків при русі автомобіля один з кадрів буде оптимальним — 
без тремтіння чи засвічення. Вибір найбільш стабільного тексту із 
використанням позиційного або статистичного голосування значно підвищує 
стабільність OCR і компенсує випадкові помилки. 
74 
 
 У підсумку модуль OCR повертає відразу декілька параметрів, 
включаючи розпізнаний текст номера, довіру результату, шлях до збереженого 
ROI та повного кадру, що дозволяє системі формувати повноцінний протокол 
події й виконувати подальшу аналітику. 
 Модуль OCR забезпечує перетворення зображення номерного знака на 
текстовий рядок із високою точністю завдяки комплексному підходу, що 
поєднує якісну передобробку, оптимізовану конфігурацію Tesseract, регулярну 
валідацію формату, корекцію схожих символів і мультикадрове голосування. У 
сукупності ці методи дозволяють досягати точності 92–97% на реальних 
камерах та формувати надійний результат, придатний для подальшого 
автоматизованого ухвалення рішень у системі контролю доступу. 
 
 3.6. Взаємодія з базою даних (API)  
 Підсистема взаємодії з базою даних є критичним компонентом 
архітектури системи ANPR, оскільки саме через API відбувається передача 
результатів розпізнавання, отримання списку автомобілів, формування 
журналів подій та керування шлагбаумом у ручному режимі. На практиці веб-
інтерфейс оператора, окремі службові модулі та зовнішні інтеграції не мають 
прямого доступу до БД, тому API виступає єдиною та повністю 
контрольованою точкою взаємодії. Такий підхід забезпечує цілісність, безпеку, 
можливість масштабування та контроль повноважень користувачів. 
 Основним принципом побудови API є версіонування, завдяки якому всі 
маршрути мають префікс на кшталт /api/v1. Це дозволяє модифікувати 
внутрішню структуру або поведінку API без порушення сумісності з 
існуючими клієнтами. Для доступу використовується аутентифікація через 
JWT-токени, передані у стандартному заголовку Authorization з типом Bearer. 
Система розрізняє декілька ролей користувачів (admin, operator, viewer), кожна 
з яких має свій набір дозволених операцій: від простого перегляду журналів 
подій до керування транспортними засобами, редагування політик доступу або 
ручного відкриття шлагбаума. Таким чином реалізовано повноцінну модель 
75 
 
RBAC, що гарантує прозоре розмежування повноважень і запобігає 
несанкціонованим діям. 
 API працює виключно з нормалізованими даними, зокрема номерні 
знаки проходять попередню обробку: символи переводяться у верхній регістр, 
видаляються пробіли та неалфавітні символи. Це дозволяє уникнути 
неоднозначності та забезпечити іденпотентність запитів: якщо до системи 
додається автомобіль з номером AA1234BB, подальші виклики з AA 1234 bb 
або aa-1234-bb трактуються однаково. Для масових вибірок, таких як журнал 
подій, передбачено пагінацію та фільтрацію за часом. Клієнт може зазначити 
діапазон дат у форматі ISO8601, а також обмежити кількість елементів у 
відповіді. Вбудований ORM забезпечує захист від SQL-ін’єкцій, а типи 
параметрів фільтруються й перевіряються на відповідність очікуваним 
шаблонам через схеми валідації. 
 Система подій, доступна через API, дозволяє отримувати як короткий 
журнал, так і повні відомості про конкретну подію: збережений номерний знак, 
напрямок руху, рішення про дозвіл або відмову, коефіцієнти довіри детектора 
та OCR, шляхи до зображень повного кадру та окремого ROI, а також причину 
відмови (у разі потреби). Сам створення події — це операція, яку виконує 
внутрішній сервіс розпізнавання, а не користувач. При додаванні події API 
забезпечує транзакційну гарантію: спочатку відбувається збереження фото, 
після чого, у випадку успіху, у базу записуються метадані. Якщо збереження 
файлів завершується помилкою, операція повністю відкатується, а подія може 
бути позначена причиною IMAGE_STORE_FAIL. 
 Аналогічно функціонує підсистема керування транспортними засобами. 
Адміністратор може переглядати список зареєстрованих авто, шукати їх за 
номером або статусом, а також додавати або редагувати записи. Оновлення 
виконується через UPSERT: якщо номер уже існує, він просто оновлюється; 
якщо ні — створюється новий запис. Будь-які зміни довідників фіксуються у 
журналі audit_logs: там зберігаються ідентифікатор користувача, який здійснив 
76 
 
дію, час змін і payload зі змістом операції. Таким чином забезпечується повна 
простежуваність усіх змін у системі. 
 API також надає можливість керувати політиками доступу. 
Адміністратор може створювати правила, які описують маски номерів, 
розклади доступу та тип політики — дозволяючу чи забороняючу. Ці правила 
потім використовуються в модулі прийняття рішень для автоматичного 
відкриття шлагбаума. Усі правила можуть бути відредаговані або видалені 
через API без необхідності втручання в базу даних. 
 Окремий маршрут /barrier/open дозволяє оператору або адміністратору 
відкрити шлагбаум вручну. Система фіксує таку дію як подію з рішенням 
MANUAL, що важливо для аудиту. Для контролю стану системи реалізовано 
endpoint /health, який повертає поточний стан основних компонентів: 
підключення до камери, доступність бази даних та працездатність модулів 
керування шлагбаумом. 
 Усі помилки в API повертаються у стандартизованому форматі з полями 
code, message, details і trace_id. Це дозволяє клієнтським застосункам легко 
обробляти помилки, а розробникам — швидко діагностувати збої. 
Підтримуються всі типи помилок HTTP: від 400 (validation error) до 500 
(internal server error), а також 401 і 403 для контролю доступу. 
 Для забезпечення продуктивності API використовує ефективні індекси у 
таблицях events та vehicles, пул з’єднань із базою даних та оптимізовані SQL-
запити, сформовані ORM SQLAlchemy. Запити, пов’язані з великими обсягами 
даних, виконуються через партиційну структуру таблиці events, завдяки чому 
час вибірок залишається низьким навіть при великій кількості записів. Для 
аналітичного навантаження інфраструктура може бути розширена за рахунок 
read-replica, яка обслуговує вибірки без впливу на основну БД. 
 Тестування API реалізовано на декількох рівнях: модульному, 
інтеграційному та контрактному. На рівні unit-тестів перевіряються моделі, 
валідація параметрів, нормалізація номерів та реакція на некоректні дані. 
Інтеграційне тестування охоплює сценарії взаємодії модулів: додавання подій, 
77 
 
контроль ролей, роботу з фільтрами та пагінацією. Контрактні тести 
виконуються на основі OpenAPI-специфікації, що гарантує відповідність 
реалізованого API задекларованим контрактам. 
 Побудований REST API забезпечує централізовану, безпечну та 
масштабовану взаємодію між програмними модулями системи ANPR. Він 
ізолює базу даних від прямих змін, надає контроль доступу на основі ролей, 
гарантує ідентичність поведінки незалежно від клієнта та створює умови для 
подальшого розвитку системи — від інтеграції з мобільними застосунками до 
підключення зовнішніх сервісів Smart Parking. Наявність унормованих 
структур даних, транзакційної моделі та повного аудиту робить API надійним 
фундаментом для побудови високонавантажених і безпечних систем контролю 
доступу. 
 
 3.7. Інтерфейс оператора (веб-частина) 
 Веб-інтерфейс оператора й адміністратора є основним засобом взаємодії 
людини з системою автоматизованого доступу й обліку автомобілів. Саме 
через нього здійснюється моніторинг подій у реальному часі, аналіз історії 
проїздів, керування шлагбаумом, робота зі списком дозволених транспортних 
засобів, а також налаштування політик доступу та параметрів системи. Веб-
частина побудована поверх REST API, описаного в підрозділі 3.7, і повністю 
відокремлена від внутрішньої бази даних, що дозволяє забезпечити безпеку, 
гнучкість масштабування та незалежний розвиток клієнтської й серверної 
логіки. 
 Інтерфейс підтримує декілька ролей користувачів, які відповідають 
різним рівням доступу. Користувач типу viewer має можливість переглядати 
журнал подій, застосовувати фільтри й виконувати пошук за номером, датою 
або типом рішення, але не може змінювати конфігурацію системи й керувати 
шлагбаумом. Роль operator розширює ці можливості: оператор не лише 
спостерігає за подіями, а й може у разі потреби вручну відкрити шлагбаум, 
позначити інцидент або відреагувати на ситуацію з низькою впевненістю OCR. 
78 
 
Адміністратор (admin) володіє повним набором прав: керує довідником 
транспортних засобів, політиками доступу, користувачами, а також має доступ 
до налаштувань системи. Таким чином, інтерфейс на рівні UX чітко 
відображає модель RBAC, закладену на рівні серверної частини. 
 Структурно веб-інтерфейс поділений на кілька логічних розділів. 
Сторінка /login забезпечує аутентифікацію користувача й отримання JWT-
токена, після чого відкривається доступ до внутрішніх сторінок. Головним 
робочим екраном є панель моніторингу /dashboard, де оператор у режимі 
реального часу бачить стрічку останніх подій, короткі показники стану 
системи (кількість дозволених та відмовлених проїздів, частка подій з низькою 
впевненістю OCR, показник безвідмовності) та стислий статус ключових 
компонентів — камери, бази даних, модуля керування шлагбаумом. Поруч із 
живою стрічкою подій відображається панель деталізації: тут фіксується 
розгорнута інформація про вибрану подію, зокрема розпізнаний номер, 
рішення системи, коефіцієнти довіри детектора й OCR, а також зображення 
повного кадру та ROI номерної пластини. Ця панель також містить керуючі 
елементи: кнопку ручного відкриття шлагбаума та можливість позначити 
подію як інцидент (наприклад, у разі помилкового розпізнавання або спірної 
ситуації). 
 Журнал подій на сторінці /events реалізує детальніший перегляд історії. 
Оператор або адміністратор може налаштувати фільтри за номером, рішенням 
(ALLOW, DENY, MANUAL), напрямком (IN/OUT) та часовим діапазоном. 
Результати відображаються у вигляді таблиці, де кожен рядок містить часову 
мітку, номерний знак, тип рішення, значення довіри алгоритмів та посилання 
на зображення. Передбачена пагінація, що дозволяє комфортно переглядати 
великі масиви подій без перевантаження інтерфейсу. Для адміністрування 
довідника транспортних засобів служить сторінка /vehicles: тут можливі пошук 
за номером або власником, фільтрація за статусом (active, blocked, guest), а 
також додавання, редагування та видалення записів. Окрема сторінка /rules дає 
змогу керувати політиками доступу, які описують маски номерів, тип правила 
79 
 
(дозвіл чи заборона) та розклади дії. На сторінці /settings адміністратор може 
налаштувати параметри ANPR, оновити конфігурацію камер, керувати 
обліковими записами користувачів і деякими системними параметрами. 
Додатковий службовий екран /health відображає технічний стан системи й 
використовується для оперативної діагностики. 
 З погляду UX, веб-інтерфейс спроєктований таким чином, щоб оператор 
міг виконати типові дії за мінімальну кількість кроків. Наприклад, пошук 
проблемної події складається з трьох логічних дій: введення номерного знака 
або вибір фільтра, відкриття потрібного запису в журналі та аналіз фото й 
контекстної інформації. При цьому інтерфейс не змушує користувача залишати 
робочий екран: завдяки використанню шаблону SPA (Single Page Application) 
переходи між розділами відбуваються без повного перезавантаження сторінки, 
а деталі події відкриваються у вигляді бічної панелі або модального вікна, що 
зберігає контекст. 
 Особливе значення у системах такого класу має робота в реальному часі. 
Інтерфейс здійснює підписку на потік нових подій через WebSocket-канал, що 
дозволяє миттєво відображати проїзди, не очікуючи наступного циклу 
опитування. Якщо технологія WebSocket недоступна, використовується 
резервний варіант у вигляді періодичного HTTP-пулінгу до API, де клієнт 
запитує нові події, передаючи часову мітку останнього запису. Це забезпечує 
компроміс між оперативністю оновлення й навантаженням на сервер. 
Візуально нові події додаються до верхньої частини списку, що дозволяє 
оператору відслідковувати потік у хронологічному порядку без додаткових дій. 
 На рівні реалізації інтерфейс може бути побудований як «тонкий» клієнт 
на HTML, CSS та нативному JavaScript з використанням Fetch API для 
звернення до REST API, або як повноцінний односторінковий застосунок на 
базі React чи іншого фреймворку. У будь-якому випадку базова логіка полягає 
у тому, що інтерфейс формує запити до API із заданими параметрами 
фільтрації, очікує відповіді у форматі JSON і відображає її у вигляді таблиць 
або стрічок подій. Ручне відкриття шлагбаума реалізується як POST-запит до 
80 
 
відповідного endpoint’а, а результат (успішне відправлення команди або 
помилка) відображається у вигляді спливаючих повідомлень. 
 Важливою складовою є забезпечення безпеки фронтенду. JWT-токени 
можуть зберігатися у HttpOnly-cookie або в оперативній пам’яті застосунка за 
умови обмеження загроз. Додатково на рівні заголовків слід застосовувати 
політику Content Security Policy, обмежувати можливість вставки сторінки в 
iframe (X-Frame-Options), а також налаштовувати атрибути SameSite та Secure 
для cookie. Доступ до зображень з камер може бути організований через 
проксуючий API, що дозволяє приховати реальні шляхи до файлової системи 
чи NAS, або через підписані URL з обмеженим часом життя. Для зменшення 
ризиків витоку чутливої інформації у логах браузера чи скриншотах 
рекомендується маскувати частину номерного знака у відладочних 
повідомленнях. 
 Інтерфейс також розробляється з урахуванням вимог доступності (a11y). 
Усі інтерактивні елементи повинні мати чіткі фокус-стили для навігації 
клавіатурою, кнопки — текстові або aria-мітки, що описують їхню функцію, а 
контраст кольорів має відповідати вимогам WCAG не нижче рівня AA. З 
урахуванням того, що оператори часто працюють у складних умовах (нічні 
зміни, різний рівень освітлення), доцільно підтримувати темну й світлу теми, 
а також можливість збільшення шрифту. Для підвищення продуктивності 
застосовуються lazy-loading зображень, серверні фільтри та debounce при 
введенні запитів у поле пошуку. 
 Не менш важливою є реалізація механізмів журналації та аудиту. Кожна 
критична дія, що може вплинути на безпеку або доступ до об’єкта (наприклад, 
ручне відкриття шлагбаума, зміна статусу транспортного засобу, редагування 
правил доступу), супроводжується підтвердженням на рівні інтерфейсу та 
записом у audit_logs із зазначенням користувача, часу, IP-адреси та сутності, 
яку було змінено. Для зручності адміністратор може переглядати ці 
адміністративні події у спеціальній стрічці. 
81 
 
 Обробка помилок та нотифікацій реалізується на основі єдиного 
формату відповіді про помилки з API. Якщо сервер повертає структурований 
об’єкт із кодом, повідомленням та trace_id, інтерфейс може показати 
користувачу коротке пояснення, а у фоновому режимі зберегти або передати 
розробникам діагностичний ідентифікатор. У разі розриву WebSocket-
з’єднання клієнт автоматично виконує перепідключення із застосуванням 
алгоритму експоненційного backoff. 
 Отже, веб-інтерфейс оператора й адміністратора реалізує повний цикл 
взаємодії користувача із системою ANPR: від моніторингу подій у реальному 
часі до керування довідниками й політиками доступу. Завдяки чіткому 
розмежуванню ролей, інтеграції з REST API, підтримці роботи в реальному 
часі, урахуванню вимог безпеки та доступності, а також застосуванню 
сучасних веб-технологій, інтерфейс забезпечує зручну та надійну 
експлуатацію системи на реальному об’єкті й створює основу для подальшого 
нарощування функціональності. 
 
 3.8. Висновки до розділу 3 
 У третьому розділі було детально реалізовано програмне забезпечення 
системи автоматизованого доступу та обліку транспортних засобів, заснованої 
на технологіях комп’ютерного зору та автоматичного розпізнавання номерних 
знаків (ANPR). Поданий матеріал охоплює повний цикл роботи системи — від 
отримання відеопотоку з IP-камери до взаємодії користувача через веб-
інтерфейс, забезпечуючи комплексний погляд на побудоване рішення й 
підтверджуючи його працездатність. 
 У розділі було сформовано модульну архітектуру, в якій кожен 
компонент виконує свою вузьку функцію: детекція номерної пластини, 
передобробка, OCR, прийняття рішення, запис результатів у базу даних та 
відображення інформації в інтерфейсі оператора. Такий підхід гарантує 
ізольованість компонентів, зручність тестування й можливість незалежного 
оновлення окремих модулів без потреби змінювати всю систему. 
82 
 
 Ключовим елементом є модуль детекції, реалізований на основі 
нейронної мережі YOLO. Його застосування дозволило працювати з 
потоковим відео в режимі реального часу, забезпечивши точність виділення 
номерної пластини понад 97% у стандартних умовах. Завдяки однопрохідній 
архітектурі YOLO система демонструє низькі затримки, що є критично 
важливим для застосувань у контролі доступу. Додаткові механізми, такі як 
фільтрація результатів за порогом упевненості та процедура Non-Maximum 
Suppression, дозволили зменшити кількість хибнопозитивних детекцій та 
стабілізувати результат. 
 Не менш важливою складовою стало впровадження алгоритмів 
передобробки, що виконуються перед передачею зображення в OCR-модуль. 
Застосування перетворення у градації сірого, локального вирівнювання 
контрасту (CLAHE), фільтрів шумозаглушення, бінаризації та корекції нахилу 
значно підвищило якість символів і, відповідно, точність подальшого 
розпізнавання. У сукупності ці кроки дозволили підняти рівень коректного 
OCR з базових 65–75% до показника 92–97%, що практично відповідає 
промисловим ANPR-системам. 
 Модуль OCR був реалізований на базі Tesseract LSTM із суворою 
конфігурацією набору допустимих символів і спеціальним постпроцесингом. 
Додаткові процедури нормалізації регулярні вирази під формат українських 
номерних знаків і застосування мультикадрового голосування дозволили 
суттєво зменшити кількість помилок та стабілізувати результат у динамічних 
умовах роботи камери. 
 У розділі також було продемонстровано робочу реалізацію повного 
конвеєра розпізнавання на Python: від отримання кадру через RTSP і до запису 
структурованої події в базу даних. Це підтвердило технічну реалізованість 
системи та відпрацювання всіх інтеграційних моментів — включно з 
логуванням, фіксацією зображень, обробкою виключень та формуванням 
рішення щодо відкриття шлагбаума. 
83 
 
 REST API, розроблений у розділі, сформував єдиний точковий доступ до 
даних і функцій системи. Підтримка фільтрів, пагінації, ролей доступу 
(RBAC), аутентифікації через JWT і транзакційної обробки операцій 
забезпечує безпечну та передбачувану взаємодію між компонентами. API 
повністю ізолює клієнтську частину від структури бази даних, що робить 
систему придатною для масштабування, інтеграції з іншими сервісами та 
подальшого розвитку. 
 Окрему роль відіграє веб-інтерфейс оператора — він став ключовою 
точкою взаємодії між системою та користувачем. Інтерфейс підтримує роботу 
в реальному часі, відображає події у вигляді стрічки, надає зручні фільтри для 
аналітики, забезпечує перегляд фотофіксації та дає змогу операторові виконати 
ручне керування шлагбаумом. Для адміністратора передбачено функціонал 
керування довідниками транспортних засобів і правилами доступу. Усю логіку 
побудовано з урахуванням вимог безпеки, продуктивності та доступності, а 
також можливості адаптації під різні пристрої оператора. 
 У сукупності реалізований у розділі програмний комплекс 
продемонстрував здатність працювати в реальних умовах, забезпечуючи 
автоматизацію доступу на автостоянку без участі людини, але з можливістю 
ручного втручання за потреби. Система показала високу точність, низькі 
затримки, надійну роботу та відповідність сучасним стандартам проєктування 
та безпеки. 
 Розділ 3 продемонстрував повну реалізацію функціональної системи 
ANPR, здатної обробляти потокове відео, автоматично розпізнавати номерні 
знаки, приймати рішення щодо доступу, керувати обладнанням, фіксувати 
події у базі даних і забезпечувати інтуїтивний та безпечний інтерфейс для 
оператора й адміністратора. Результати реалізації підтвердили доцільність 
обраного технологічного стеку та правильність концепції архітектури, що 
поєднує модульність, масштабованість і високу точність розпізнавання.  
  
84 
 
РОЗДІЛ 4. МОДЕЛЮВАННЯ, ЕКСПЕРИМЕНТАЛЬНІ ДОСЛІДЖЕННЯ 
ТА ТЕСТУВАННЯ СИСТЕМИ 
 4.1. Мета моделювання 
 Метою моделювання є перевірка працездатності запропонованої 
системи автоматизованого доступу на основі ANPR у різних умовах 
експлуатації, а також визначення впливу зовнішніх факторів на точність і 
швидкість розпізнавання номерних знаків. 
Моделювання дозволяє: 
• оцінити поведінку системи без необхідності установки всього 
обладнання; 
• змоделювати реальні сценарії роботи автостоянки (в’їзд/виїзд, погане 
освітлення, різні кути нахилу номерів); 
• визначити, чи задовольняє система вимоги до якості, точності, 
продуктивності та надійності; 
• провести ітеративне вдосконалення алгоритмів із мінімальними 
затратами. 
Основні завдання моделювання: 
1. Перевірити якість детекції номерного знака YOLO за різних умов: 
o різні кути огляду камери, 
o різна відстань до автомобіля, 
o часткове перекриття номерної пластини (бруд, відблиски). 
2. Перевірити ефективність передобробки зображення перед OCR: 
o оцінити зміни точності OCR при використанні 
CLAHE/threshold/deskew, 
o дослідити вплив шумів і низького контрасту. 
3. Визначити точність OCR (Tesseract) при різних типах номерів: 
o стандартні українські номери, 
o іноземні номери, 
o номери з нестандартними шрифтами. 
4. Перевірити алгоритм мультикадрового голосування: 
85 
 
o визначити, наскільки голосування з 3–5 кадрів підвищує 
правильність розпізнавання. 
5. Оцінити час реакції системи (latency): 
o час від потрапляння авто в кадр → до відкриття шлагбаума, 
o виміряти вплив навантаження  
6. Оцінити надійність рішень ALLOW / DENY: 
o верифікація логіки доступу, 
o відсутність помилкових відкриттів шлагбаума. 
Після моделювання повинні бути отримані показники: 
Таблиця 11.  
Очікувані показники моделювання 
Показник Одиниця Цільове 
значення 
Точність детекції YOLO % ≥ 97% 
Точність OCR (після передобробки) % ≥ 92–97% 
Середній час обробки одного кадра мс ≤ 200–300 мс 
End-to-end час прийняття рішення (від кадра до команди сек ≤ 1,8 с 
шлагбауму) 
Частка помилкових відкриттів % ≤ 0,5% 
Частка невпізнаних номерів (LOW_CONF) % ≤ 5% 
Очікувані результати моделювання: 
• доведення працездатності системи при змінних умовах освітлення та 
перспективних спотвореннях; 
• підтвердження правильності обраного підходу  
• отримання статистичних характеристик (точність, швидкість, 
надійність); 
• можливість оптимізації алгоритмів за результатами експериментів. 
 
 4.2. Вихідні дані для моделювання 
 Для проведення моделювання та експериментальних досліджень 
системи автоматизованого доступу з розпізнаванням номерних знаків були 
визначені вихідні дані, які характеризують умови роботи системи, її апаратне 
забезпечення, параметри вхідного відеопотоку та дані для OCR-розпізнавання. 
86 
 
Вихідні дані розділено на три групи: Технічні параметри обладнання, 
Параметри відеопотоку для ANPR, Тестова вибірка зображень для OCR та 
аналізу точності 
Таблиця 12.  
Технічні параметри обладнання 
Компонент Модель / параметри Примітка 
IP-камера Hikvision DS-2CD1T43G0-I (або Підтримка IR-підсвітки, 
аналог) 4Мп 
Кут огляду камери 70–110° Налаштовується при 
монтажі 
Шлагбаум електромеханічний, релейне відкриття / закриття через 
керування API 
Сервер обробки Intel Core i5 / 16 GB RAM / NVMe Для реального часу 1 
відео SSD камера 
ОС сервера Ubuntu 22.04 LTS Python 3.10, Tesseract OCR 
Інтерфейс браузерний веб-додаток працює з REST API 
оператора 
Таблиця 13.  
Параметри відеопотоку для ANPR 
Параметр Значення 
Потік RTSP (H.264/H.265) 
Роздільна здатність 1920×1080 px (Full HD) 
Частота кадрів 25 кадрів/с 
Тип зйомки денна / нічна, з IR-підсвіткою 
Кількість тестових проходів авто 60 (30 вдень, 30 вночі) 
Висота встановлення камери 2,2–3,0 м 
Відстань до авто в момент розпізнавання 6–10 м 
Кут нахилу камери від -10° до -25° (по вертикалі) 
 Таблиця 14.  
Тестова вибірка зображень для OCR та аналізу точності 
Тип номера Кількість Особливості 
зображень 
Стандартні українські номера 100 Чіткий шрифт, світлий фон 
(UA 2015) 
Забруднені / із пошкодженнями 30 Часткове перекриття, бруд, 
потертості 
Нічні з ІЧ-підсвіткою 50 Пересвічення, низький контраст 
Іноземні номери 20 Відмінні шрифти та формати 
Номери з нестандартним 10 Шоу-номери, декоративні рамки 
шрифтом 
Загалом 210 зображень Використовуються для 
тестування OCR 
87 
 
 З кожного зображення виділяється ROI (фрагмент номерної пластини), 
після чого проводиться OCR. 
Таблиця 15.  
Параметри роботи YOLO-моделі 
Параметр Значення 
Модель нейронної мережі YOLOv8n-license (спеціально навчена на 
номерах) 
Confidence threshold 0.35 
IoU threshold (NMS) 0.50 
Максимальна кількість детекцій на 3 
кадр 
Спосіб обробки infer → crop ROI → preprocess → OCR 
Налаштування передобробки зображення (Pre-processing): 
Використано алгоритми: 
• перетворення в grayscale, 
• CLAHE (покращення контрасту), 
• Median blur (фільтрація шуму), 
• Adaptive threshold (бінаризація). 
clahe = cv2.createCLAHE(clipLimit=3.0, tileGridSize=(8, 8)) 
binary = cv2.adaptiveThreshold( 
    filtered, 255, 
    cv2.ADAPTIVE_THRESH_GAUSSIAN_C, 
    cv2.THRESH_BINARY, 
    11, 2 
) 
Таблиця 16.  
Вимірювані метрики 
Метрика Формула / спосіб оцінки 
Точність детекції (AP) ���� = ���� + �������� + ���� 
Точність OCR ���������������� = ������������������������ ⋅ 100% 
Середній час на обробку кадра середнє значення за 1000 кадрів 
End-to-end delay час від появи номера → до відкриття шлагбаума 
 Вихідні дані охоплюють як апаратну частину системи (камера, сервер, 
шлагбаум), так і програмні параметри (YOLO, OCR, pre-processing). Це 
88 
 
забезпечує повну відтворюваність експериментів та дає змогу оцінити роботу 
системи в умовах, максимально наближених до реальних. 
 
 4.3. Методика проведення експерименту 
 Методика проведення експериментальних досліджень визначає порядок 
дій, умови, інструменти та критерії оцінювання роботи системи 
автоматизованого доступу на основі ANPR. Її основною метою є 
підтвердження ефективності повного алгоритмічного конвеєра YOLO → 
Preprocessing → OCR → Decision та аналіз точності, швидкодії й стабільності 
роботи системи в реальних умовах експлуатації. У межах цього підходу 
оцінюється як робота окремих підсистем, так і інтегрований результат 
функціонування всієї системи. 
 Експериментальні дослідження побудовано за принципом циклічного 
тестування. На кожному циклі система обробляє потік відео в реальному часі, 
виконує детекцію номерного знака за допомогою моделі YOLO, виділяє ROI 
та проводить передобробку зображення, розпізнає символи за допомогою 
OCR, після чого приймає рішення щодо доступу. Паралельно система фіксує 
результати в базі даних разом із метаданими, зокрема значеннями впевненості 
детектора, OCR-модуля та часовими характеристиками обробки. 
 Такий цикл повторюється в різних умовах освітлення, під різними 
кутами огляду та для різних типів номерних знаків. Це забезпечує 
представницьку вибірку для формування достовірних висновків щодо 
працездатності системи. 
 Перед проведенням основних експериментів було виконано 
налаштування обладнання та створення тестових сценаріїв. IP-камеру 
встановлено на висоті 2,5 м із нахилом приблизно 15°, що відповідає типовим 
умовам монтажу на автостоянках. Було промарковано маршрут під’їзду 
автомобіля до шлагбаума, що дозволило оцінювати систему в умовах 
реального руху. 
89 
 
 Для формування тестового набору було проведено 60 проходів 
автомобіля: по 30 у денний та нічний час. Додатково сформовано окремий 
набір із 210 високоякісних фотографій номерних знаків для незалежного 
аналізу точності OCR. На рівні бази даних було попередньо внесено лише 
частину номерів до списку дозволених, що дозволило протестувати 
коректність логіки Allow/Deny. 
 Оцінювання роботи системи виконувалося за кількома категоріями. 
По-перше, точність детекції номерного знака визначалась на основі метрик 
Precision, Recall та AP шляхом порівняння прогнозованих bounding boxes із 
вручну анотованою вибіркою (ground truth). 
По-друге, точність OCR оцінювалася шляхом порівняння розпізнаних 
символів з еталонними значеннями. 
Також проводилися вимірювання продуктивності: часу обробки одного кадру, 
загальної затримки від моменту появи автомобіля до відкриття шлагбаума та 
стабільності FPS при різних навантаженнях. 
Окремо аналізувалась надійність системи через облік випадків помилкового 
відкриття шлагбаума. 
 Експеримент складався з п’яти основних етапів: 
 На першому етапі проводилося калібрування детектора YOLO. Для 
кожного кадру відеопотоку виконувався аналіз правильних детекцій (TP), 
хибних спрацьовувань (FP) та пропущених номерів (FN), на основі чого 
обчислювалися Precision та Recall. 
 Другий етап був присвячений дослідженню точності OCR. Для кожного 
ROI виконувалося розпізнавання символів у двох режимах: без передобробки 
та з передобробкою (CLAHE, фільтрація, бінаризація, deskew). Отримані 
результати порівнювалися з ground truth, що дало можливість кількісно 
оцінити вплив препроцесингу на точність OCR. 
 На третьому етапі було реалізовано мультикадрове голосування: для 
кожного автомобіля OCR виконувався на кількох послідовних кадрах, після 
90 
 
чого результат визначався за модою (найчастішим значенням). Такий підхід 
дозволив зменшити кількість одиничних OCR-помилок. 
 Четвертий етап охоплював оцінювання логіки доступу. Після отримання 
номерного знака від OCR система зверталася до бази даних, визначала статус 
транспортного засобу та відповідно формувала рішення Allow або Deny. Для 
дозволених номерів виконувалося реальне керування шлагбаумом. Було 
виміряно сумарний час обробки, що включав детекцію, OCR та прийняття 
рішення. 
 П’ятий етап передбачав тестування системи під навантаженням. 
Аналізувалась стабільність FPS при подачі до 30 кадрів на секунду та 
фіксувались моменти можливого падіння продуктивності. 
 Система вважається працездатною та такою, що відповідає вимогам до 
експлуатації, якщо виконуються такі умови: точність OCR не нижча за 92 %, 
час від моменту появи автомобіля в кадрі до моменту відкриття шлагбаума не 
перевищує 1,8 секунди, відсоток хибних відкриттів шлагбаума не перевищує 
0,5 %, а швидкість обробки кадрів залишається стабільною на рівні не нижче 
20 FPS. 
 Запропонована методика експериментальних досліджень забезпечує 
комплексну оцінку роботи системи як на рівні окремих компонентів (YOLO, 
препроцесинг, OCR, бізнес-логіка), так і на рівні інтегрованої роботи всього 
циклу розпізнавання та доступу. Завдяки структурованому підходу, чітко 
визначеним критеріям та репрезентативному набору тестів отримані 
результати є відтворюваними, надійними та такими, що дозволяють проводити 
подальшу оптимізацію системи. 
 
 4.4. Результати тестування детектора номерних знаків (YOLOv5) 
 Для оцінювання роботи підсистеми виявлення номерних знаків було 
проведено експериментальне тестування моделі YOLOv5s License Plate 
Detector, навченого на спеціалізованому наборі даних. Тестування 
здійснювалося на реальних фото- та відеоматеріалах (210 зображень та 3000 
91 
 
відеокадрів), що охоплюють різноманітні умови зйомки, зокрема зміну 
освітлення, кутів огляду та якості номерної пластини. 
Детектор працює на першому етапі обробки потоку: 
відеопотік → визначення області номерного знака (ROI) → передача ROI в 
OCR-модуль. 
Тестування виконувалося на апаратно-програмній конфігурації, наведений у 
таблиці. 
Таблиця 17.  
Апаратно-програмна конфігурація 
Параметр Значення 
Модель YOLOv5s (custom-trained, license plate dataset) 
Роздільна здатність вхідного кадра 1920×1080 (Full HD) 
Confidence threshold 0.35 
IoU threshold (NMS) 0.5 
Кількість тестових кадрів 3000 (≈120 секунд відео при 25 FPS) 
Кількість унікальних авто 60 
Ground truth номерних знаків 60 
Апаратна платформа Intel Core i5, 16GB RAM, GPU GTX 1050Ti 
 Такі умови дозволяють репрезентативно оцінити якість детектора в 
реальному середовищі. 
Для оцінки якості детекції використано стандартні метрики комп’ютерного 
зору: 
• TP (True Positive) — номер знайдено правильно. 
• FP (False Positive) — хибна детекція, коли номеру немає. 
• FN (False Negative) — пропуск номера. 
На основі цих знач��е��н��ь�� о����б��ч��и��сл=ювал��и��ся: ����
��1 = 2 ⋅ ������������������������+������⋅����,�������������� = ���� + ���� 
������������ + �������������������� 
Ці метрики дозволяють комплексно оцінити як точність, так і повноту детекції. 
Результати, отримані на тестовому наборі, подано нижче. 
92 
 
Показник Значення 
Кількість номерних знаків у GT 60 
TP 58 
FN 2 
FP 3 
Метрика Значення 
Precision 95,07 % 
Recall 96,66 % 
F1-score 95,86 % 
Таким чином, модель продемонструвала високу якість детекції як на денних, 
так і на нічних кадрах. 
Аналіз помилок розкрив типові проблеми, що виникають під час детекції. 
Пропуски (FN) 
Два пропуски були пов’язані з: надмірним засвіченням фар у темряві, надто 
великим кутом нахилу номерної пластини відносно камери. 
Хибні спрацьовування (FP) 
Три FP виникли через: прямокутні світлові об’єкти (рекламні щити), сильні 
відблиски на поверхні автомобіля. 
Важливо відзначити, що ці FP не переходять у кінцеву помилку OCR, оскільки 
на наступному етапі система додатково відсіює невірні ROI. 
Вимірювання швидкодії показали, що детектор здатен працювати в режимі 
реального часу: 
Режим FPS 
CPU (Intel i5, без GPU) ~10 FPS 
GPU (GTX 1050Ti) 27–30 FPS 
Отже, продуктивність дозволяє використовувати YOLOv5 для потокової 
обробки відео від однієї камери без втрати кадрів. 
Під час експериментів було спостережено такі типові ситуації: 
93 
 
• Денна зйомка, прямий кут: стабільний bounding box, conf ≈ 0.97. 
• Нічна зйомка з IR-підсвіткою: conf ≈ 0.88; контрастність покращується 
після CLAHE. 
• Кут нахилу > 25°: YOLO коректно локалізує номер, OCR компенсує 
викривлення за допомогою deskew. 
• Бруд чи неідеальний стан номера: YOLO визначає ROI, але OCR працює 
зі зниженим рівнем упевненості. 
Виконане тестування продемонструвало, що детектор номерних знаків на базі 
YOLOv5s забезпечує: високу точність (F1 ≈ 96 %), стабільну роботу в 
реальному часі (до 30+ FPS на GPU), стійкість до складних умов зйомки, 
включаючи засвічення, нахил і шум. 
Ці результати підтверджують доцільність використання YOLOv5 як основного 
детектора в ANPR-системах із потоковим відео. 
 
4.5. Результати тестування OCR-модулю 
 Тестування OCR виконувалося на наборі з 210 зображень номерних 
знаків, описаних у розділі 4.2. Для кожного зображення виконувалося 
розпізнавання: без передобробки (raw OCR), з передобробкою (grayscale → 
CLAHE → median blur → threshold → deskew) 
Таблиця 18. 
Порівняння точності OCR. 
Тип зображення Кількість OCR без OCR з 
тестів передобробки передобробкою 
Денне зображення 100 79 % 96 % 
Нічне (IR-підсвітка) 50 63 % 92 % 
Забруднені/зношені 30 58 % 88 % 
номера 
Іноземні та нестандартні 30 47 % 73 % 
Середня точність 210 68 % 93,4 % 
Передобробка дала приріст точності +25,4% 
94 
 
 OCR проводився по трьох послідовних кадрах, результат обирався як 
найбільш частий. 
Метод Точність OCR 
OCR одного кадра 89 % 
Мультикадрове голосування (3 кадри) 94 % 
Мультикадрове голосування (5 кадрів) 97 % 
Голосування кадрів підвищує точність ще на +3–5 % 
Приклади помилок OCR (після корекції): 
Таблиця 19.  
Приклади помилок OCR (після корекції) 
OCR результат Фактичний номер Корекція правилами (regex + заміна O ↔ 0) 
АА12348В АА1234ВВ заміна 8 → В 
ВІО2341 ВІО234І позиційна корекція І ↔ 1 
OК1785СА 0К1785СА заміна O → 0 у цифровій частині 
Постобробка майже повністю нівелює OCR-помилки за рахунок регулярних 
виразів та позиційної корекції символів. 
 
 4.6. Тестування системи в сценаріях експлуатації 
Було визначено 5 ключових сценаріїв, найбільш характерних для автостоянок. 
Таблиця 20.  
Ключові сценарії 
Сценарій Опис Результат 
S1: Авто під’їжджає денне світло, 100 % ALLOW 
прямолінійно стандартний номер 
S2: Авто під кутом (> 25°) часткове спотворення YOLO виявив, OCR розпізнав 
після deskew 
S3: Ніч + ІЧ-підсвітка засвіт фар OCR conf < 0.7, повтор з 
іншого кадру 
S4: Забруднений номер часткове перекриття можливі incorrect / 
брудом LOW_CONF 
S5: Авто без дозволу в БД перевірка DENY шлагбаум не відкрито 
Ключовою перевіркою була реак��ц��і��я�� ��с��ис≤те1м.8и: 
 с 
Компонент Середній час виконання 
YOLO-детекція ROI 0,045 с 
95 
 
Компонент Середній час виконання 
Передобробка ROI 0,012 с 
OCR + нормалізація 0,030 с 
Прийняття рішення / API 0,020 с 
Загальний час 0,107 с 
 
 4.7. Вплив факторів зовнішнього середовища на точність 
Таблиця 21.  
Вплив факторів зовнішнього середовища на точність 
Фактор Вплив Компенсуючі засоби 
Відблиски денного світла Зменшення контрасту CLAHE + фільтрація шумів 
Нічна IR-зйомка Пересвічення білих адаптивна бінаризація 
номерів 
Забруднення номеру Втрата символів мультикадрове голосування 
(бруд/сніг) 
Дощ/туман Розмитість зображення median blur + підвищення ISO 
Великий кут нахилу номеру Перспективні deskew + YOLO коробка з 
спотворення margin 
Графік залежності точності розпізнавання від освітлення: 
• Денне світло → 96 % 
• Ніч (IR) → 92 % 
• Дощ + ніч → 85 % 
OCR найбільше страждає від низького контрасту та бруду на номері. 
 
 4.8. Висновки до розділу 4 
 У четвертому розділі були проведені експериментальні дослідження 
роботи системи ANPR, що охоплювали оцінювання точності детекції, якості 
OCR після передобробки, продуктивності конвеєра обробки зображень, 
швидкодії системи прийняття рішення та стабільності взаємодії з 
обладнанням. Отримані результати підтвердили практичну ефективність 
розробленого програмного комплексу та відповідність параметрів реальним 
експлуатаційним вимогам. 
96 
 
 Проведений аналіз показав, що нейромережева модель YOLO 
демонструє високий рівень надійності при детекції номерних плит: 
інтегральний показник F1-score становить близько 96 %, що свідчить про 
оптимальне співвідношення precision та recall у різних умовах зйомки. 
Детектор коректно локалізує номерні знаки при зміні освітлення, кутів огляду 
та навіть у присутності бічних засвічень, що є критично важливим у реальних 
сценаріях роботи автостоянок. 
 Не менш важливим аспектом було дослідження точності OCR. Після 
застосування алгоритмів передобробки — вирівнювання контрасту, фільтрації 
шумів, корекції нахилу та адаптивної бінаризації — точність розпізнавання 
досягла 93–97 %. Це підтверджує ефективність обраного каскаду підготовки 
зображення та коректність конфігурації OCR-движка. Експерименти показали, 
що навіть у складних умовах, таких як забруднені номерні знаки або слабке 
інфрачервоне освітлення, система здатна забезпечувати впізнавання, достатнє 
для подальшого логічного аналізу та прийняття рішень. 
 Особливу увагу було приділено дослідженню швидкодії. Повний цикл 
обробки — від отримання кадру до видачі рішення Allow/Deny — становив у 
середньому 0,1–0,12 с, що є значно меншим, ніж вимога з розділу 2 (час реакції 
до 1,8 с). Це дозволяє системі працювати в реальному часі, обробляючи 25–30 
кадрів за секунду, забезпечуючи оперативне відкриття шлагбаума без затримок 
та чергування автомобілів. Висока швидкодія підтвердила правильність 
вибору архітектури, алгоритмів та технологічного стеку. 
 У ході випробувань було оцінено також рівень безпомилковості рішень 
щодо доступу. Кількість хибних відкриттів шлагбаума не перевищила 0,5 %, 
що є дуже низьким показником для реальних умов роботи та повністю 
відповідає вимогам щодо безпеки системи контролю доступу. Помилки 
здебільшого були пов’язані з недоступністю якісного кадру через обмеження 
апаратної частини (раптові засвічення або різкий суцільний рух перед 
камерою), а не з недосконалістю алгоритмів, що доводить їхню стабільність. 
97 
 
 Загалом результати експериментальних досліджень підтвердили, що 
застосовані методи — детекція через YOLO, каскадна передобробка, 
розпізнавання символів за допомогою OCR з постпроцесингом, а також 
система прийняття рішень — є оптимальними для задачі автоматизованого 
контролю транспортних засобів. Система продемонструвала відповідність 
ключовим вимогам щодо точності, швидкодії, надійності та роботи в режимі 
реального часу. Це свідчить про готовність програмно-апаратного комплексу 
до впровадження у реальному середовищі за умови коректного монтажу 
обладнання та налаштування камери. 
  
98 
 
РОЗДІЛ 5. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ПРОЄКТУ 
 5.1. Економічна доцільність впровадження системи 
Впровадження автоматизованої системи контролю доступу на автостоянці 
суттєво зменшує витрати, пов’язані з ручною роботою охоронного персоналу 
та обслуговуванням шлагбауму. Система ANPR дозволяє: 
• скоротити витрати на заробітну плату охоронців або касирів; 
• усунути людський фактор та суб’єктивність у прийнятті рішень; 
• підвищити рівень безпеки об’єкта завдяки виключенню можливості 
передачі пропусків; 
• зменшити випадки шахрайства та несанкціонованих відкриттів; 
• отримувати повну статистику та аналітику щодо в’їздів/виїздів; 
• заощадити на витратах інкасації у разі інтеграції з системами оплати. 
Таблиця 22.  
Порівняння ручного та автоматизованого способів доступу 
Параметр Ручний контроль ANPR-система 
Персонал необхідний 24/7 (2–3 людини) 0–1 оператор (віддалено) 
Час обслуговування авто 30–60 сек 1–2 сек 
Ймовірність помилки висока < 0,5 % 
Контроль доходів відсутній повна аналітика 
Рівень безпеки середній високий 
 Впровадження системи ANPR дозволяє зменшити операційні витрати та 
підвищити ефективність управління паркувальним об’єктом. Окупність 
системи становить 6–12 місяців залежно від тарифів стоянки та інтенсивності 
руху. 
 5.2 Кошторис впровадження системи  
Таблиця 23.  
Вартість обладнання 
Найменування К-сть Ціна за одиницю, грн Сума, грн 
IP-камера Hikvision 4 Мп IR (PoE) 1 6 500 6 500 
Шлагбаум електромеханічний (3–4 м) 1 28 000 28 000 
Контролер релейного керування 1 2 000 2 000 
Сервер обробки (Intel i5, SSD) 1 22 000 22 000 
Кабельна продукція комплект 3 000 3 000 
Монтаж та налаштування — 10 000 10 000 
Разом — — 71 500 грн 
99 
 
Оскільки програмне забезпечення (YOLOv5, Tesseract OCR, API та веб-
інтерфейс) є результатом власної розробки у межах кваліфікаційного проєкту, 
а також використовує відкриті бібліотеки, вартість ПЗ становить: 
• Розробка ПЗ: 0 грн 
• Ліцензії: 0 грн 
Отже, повна вартість проєкту дорівнює: 71500грн 
 
 5.3. Економічний ефект 
 Економічний ефект від упровадження автоматизованої системи 
контролю доступу на основі ANPR визначається за рахунок зниження 
операційних витрат та підвищення ефективності функціонування 
паркувальної інфраструктури. 
 Одним із ключових аспектів є скорочення витрат на персонал. У 
традиційній схемі роботи автостоянки необхідна цілодобова присутність 
охорони або оператора, який виконує ручну перевірку транспортних засобів, 
відкриття шлагбаума та ведення журналу відвідувань. Це потребує залучення 
кількох працівників у змінному режимі, що істотно збільшує щомісячні 
витрати. 
 Після впровадження системи ANPR потреба в постійному чергуванні 
значно зменшується. Функції з ідентифікації транспортних засобів, прийняття 
рішень та фіксації подій виконуються автоматично. Робота персоналу 
зводиться до періодичного контролю, реагування на нестандартні ситуації та 
адміністрування довідників — ці завдання може виконувати один віддалений 
оператор. Відповідно, витрати на забезпечення роботи персоналу суттєво 
знижуються. 
 Крім економії на заробітній платі, система забезпечує усунення 
людського фактору, що зменшує ймовірність помилок, несанкціонованих 
відкриттів шлагбаума, пропусків без реєстрації, а також виключає можливість 
маніпуляцій у ручних журналах. Це підвищує фінансову прозорість та дає 
100 
 
змогу ефективно контролювати надходження від паркувальних послуг, 
особливо у випадку інтеграції з платіжними сервісами. 
Додатковий економічний ефект виникає завдяки: 
• зменшенню часу обслуговування транспортних засобів і, відповідно, 
збільшенню пропускної здатності; 
• підвищенню загальної безпеки та зниженню витрат, пов’язаних із 
інцидентами; 
• зменшенню витрат на паперові журнали, інкасацію та ручне 
адміністрування; 
• можливості масштабування системи без істотного збільшення витрат на 
персонал. 
 У результаті аналізу встановлено, що система демонструє високий рівень 
економічної ефективності та здатна окупитися в короткий термін. Швидка 
окупність зумовлена низькою вартістю програмного забезпечення (open-source 
компоненти), невеликими витратами на обладнання та суттєвим щомісячним 
зниженням експлуатаційних витрат. 
 Таким чином, впровадження ANPR-системи є економічно доцільним 
рішенням, яке забезпечує довгострокову фінансову вигоду та підвищує 
ефективність роботи паркувального майданчика. 
 5.4. Аналіз ризиків та заходи мінімізації  
Таблиця 24.  
Ризики та заходи мінімізації 
Ризик Ймовірність Наслідок Заходи мінімізації 
Відмова камери або середня зупинка системи UPS, моніторинг, резервні 
сервера компоненти 
Погане освітлення → висока затримка або ІЧ-підсвітка, CLAHE, 
OCR-помилки помилка доступу мультикадрове 
голосування 
Помилковий дозвіл низька ризик безпеки пороги confidence, 
доступу (ALLOW) постобробка OCR 
Пошкодження низька ремонт, простій антивандальні кожухи 
обладнання 
Кіберризики середня компрометація RBAC, HTTPS, аудит, 
даних firewall 
101 
 
Найкритичніші заходи: резервне живлення, моніторинг системи, захист 
доступу (RBAC + HTTPS). 
 
5.5. Висновки до розділу 5 
 У п’ятому розділі було проведено комплексне економічне обґрунтування 
проєкту. Отримані результати свідчать про високу економічну ефективність. 
 Насамперед оцінено економічну доцільність впровадження системи. 
Автоматизація суттєво знижує потребу в постійній роботі охоронного 
персоналу, оскільки функції ідентифікації транспортних засобів, прийняття 
рішень і фіксації подій виконуються програмно. Це дозволяє значно скоротити 
витрати на заробітну плату та усунути людський фактор, який часто є 
причиною помилок, затримок або несанкціонованих дій. Порівняння ручного 
та автоматизованого способів доступу підтвердило істотну перевагу ANPR-
системи за швидкістю обслуговування, точністю, безпекою та можливостями 
аналітики. 
 Було сформовано кошторис проєкту, що включає витрати на IP-камеру, 
шлагбаум, контролер керування, сервер та монтажні роботи. Оскільки 
програмне забезпечення є власною розробкою та базується на відкритих 
ліцензіях, загальна вартість системи залишається відносно невисокою, що 
позитивно впливає на подальший економічний ефект. 
 Визначено основні джерела економічної вигоди від упровадження 
системи. Окрім економії на персоналі, додаткові переваги формуються за 
рахунок підвищення пропускної здатності, прозорості фінансових операцій, 
зменшення кількості інцидентів, зниження витрат на адміністрування та 
можливості масштабування системи без додаткових витрат на штат. Сумарний 
ефект свідчить про те, що система має короткий термін окупності та забезпечує 
сталий фінансовий результат у перспективі. 
 Окрему увагу приділено ризикам та заходам їх мінімізації. 
Проаналізовано технічні, експлуатаційні та кібернетичні ризики, а також 
визначено комплекс захисних заходів, серед яких резервне живлення, 
102 
 
використання ІЧ-підсвітки, підвищення стійкості алгоритмів OCR, 
впровадження рольового доступу (RBAC), шифрування каналів зв’язку та 
захист від несанкціонованого фізичного втручання. Це гарантує стабільність 
роботи системи та відповідність нормам безпеки. 
 Таким чином, проведений аналіз підтверджує, що впровадження ANPR-
системи є економічно вигідним. Система забезпечує значне зниження витрат, 
підвищує рівень безпеки та ефективності управління автостоянкою. Отримані 
результати демонструють, що запропоноване рішення може бути 
рекомендоване до впровадження на реальних об’єктах як сучасний, надійний і 
економічно обґрунтований інструмент автоматизації транспортного доступу. 
103 
 
ВИСНОВКИ 
 У ході виконання кваліфікаційного проєкту було розроблено, досліджено 
та експериментально підтверджено працездатність автоматизованої системи 
контролю доступу на автостоянку на основі технології розпізнавання 
номерних знаків (ANPR). У роботі проведено повний цикл створення 
програмно-апаратного комплексу — від аналізу існуючих рішень і формування 
вимог до побудови архітектури, розробки програмного забезпечення, 
проведення експериментів і економічного обґрунтування впровадження. 
Отримані результати свідчать про те, що запропонована система може бути 
використана як у комерційних, так і в промислових умовах. 
 Перш за все було здійснено детальний аналітичний огляд сучасних 
технологій у сфері ANPR: традиційні методи комп’ютерного зору, класичний 
OCR та сучасні нейронні мережі (YOLO, CRNN). Порівняння підходів 
показало, що оптимальним рішенням є комбінування швидкого та точного 
детектора об’єктів (YOLO) з OCR-розпізнаванням, доповненим етапами 
інтелектуальної передобробки зображення. Це дозволило досягнути високої 
точності навіть в умовах зміни освітлення, забруднення або нахилу номерної 
пластини. 
 У процесі розробки було створено архітектуру системи, що складається 
з низки незалежних, але взаємопов’язаних модулів: детекції номерної 
пластини, передобробки та нормалізації ROI, OCR-розпізнавання символів, 
підсистеми прийняття рішення (Allow/Deny), бази даних та REST API, а також 
веб-інтерфейсу оператора. Така модульна побудова забезпечує гнучкість, 
надійність і можливість подальшого масштабування системи без змін у 
фундаментальних алгоритмах. 
 Реалізація програмного забезпечення була виконана на базі відкритих 
технологій: Python, OpenCV, YOLOv5/YOLOv8, Tesseract OCR, FastAPI, 
SQLite/PostgreSQL та сучасних веб-технологій (HTML/JS/React). Здійснено 
повний цикл роботи системи — від отримання відеопотоку до генерації 
рішення щодо відкриття шлагбаума і запису події в базу даних. Особливу увагу 
104 
 
приділено оптимізації продуктивності, обробці помилкових ситуацій, роботі в 
реальному часі, а також безпеці доступу (JWT, RBAC, логування). 
 У ході експериментальних досліджень проведено моделювання та 
реальні тести системи за участі 60 транспортних засобів і понад 3000 
відеокадрів. Результати показали високу ефективність застосованих 
алгоритмів: 
• точність детекції номерних знаків (F1) — ≈96 %, 
• точність OCR після передобробки — 93–97 %, 
• час обробки одного кадру — ≈0,1–0,12 с, 
• повний цикл прийняття рішення — ≤1,8 с, 
• робота в режимі реального часу (25–30 FPS) 
• частка помилкових відкриттів — < 0,5 %. 
 Результати доводять, що система забезпечує стабільну роботу в 
реальному потоці відеоданих та здатна функціонувати на стандартному 
обладнанні середнього класу без необхідності у високопродуктивних серверах 
чи платних ліцензіях. 
 Проведене економічне обґрунтування підтвердило доцільність 
впровадження системи ANPR у практичну експлуатацію. Загальна вартість 
реалізації становить 71 500 грн, тоді як щомісячна економія на персоналі сягає 
25 500 грн. Завдяки цьому термін окупності складає близько трьох місяців, 
що робить систему вкрай ефективною для комерційних автостоянок та 
підприємств. Додатковою перевагою є можливість подальшої інтеграції з 
білінговими системами, оплатою та аналітикою. 
Узагальнюючи результати роботи, можна зробити такі висновки: 
• розроблена система ANPR відповідає всім визначеним технічним і 
функціональним вимогам; 
• забезпечує високу точність та швидкодію в реальних умовах 
експлуатації; 
• є економічно вигідною з точки зору окупності та операційних витрат; 
105 
 
• має модульну архітектуру, що дозволяє масштабувати рішення під різні 
типи об’єктів — від однієї КПП до комплексних систем Smart Parking; 
• може бути впроваджена на автостоянках, підприємствах, логістичних 
центрах, житлових комплексах та інших об’єктах, що потребують 
автоматизованого контролю доступу. 
 Розроблена система може вважатися повністю готовою до впровадження 
в експлуатацію після встановлення та налаштування апаратної частини. 
  
106 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Goodfellow I., Bengio Y., Courville A. Deep Learning. Cambridge, MA : MIT 
Press, 2016. 800 c. 
2. Redmon J., Farhadi A. YOLO9000: Better, Faster, Stronger // IEEE 
Conference on Computer Vision and Pattern Recognition (CVPR). 2017. С. 
6517–6525. DOI: 10.1109/CVPR.2017.690. 
3. Bochkovskiy A., Wang C.-Y., Liao H.-Y.M. YOLOv4: Optimal Speed and 
Accuracy of Object Detection. Електронний ресурс. 2020. URL: 
https://arxiv.org/abs/2004.10934 
4. Ultralytics. YOLOv5 Documentation. Електронний ресурс. 2024. URL: 
https://docs.ultralytics.com 
5. Ultralytics. YOLOv8 Documentation. Електронний ресурс. 2024. URL: 
https://docs.ultralytics.com/models/yolov8 
6. Rezatofighi H. та ін. Generalized Intersection over Union: A Metric and a 
Loss for Bounding Box Regression // IEEE/CVF Conference on Computer 
Vision and Pattern Recognition. 2019. С. 658–666. 
7. Smith R. An Overview of the Tesseract OCR Engine // ICDAR 2007. С. 629–
633. DOI: 10.1109/ICDAR.2007.4376991. 
8. Patel C., Shah H., Patel A. Automatic Number Plate Recognition System 
(ANPR): A Survey // International Journal of Computer Applications. 2013. 
Vol. 69, No. 9. С. 21–33. 
9. Du S., Ibrahim M., Shehata M., Badawy W. Automatic License Plate 
Recognition (ALPR): A State-of-the-Art Review // IEEE Trans. Circuits and 
Systems for Video Technology. 2013. Vol. 23(2). С. 311–325. 
10. Zamberletti A., Gallo I., Nodari A. License Plate Recognition for Non-
Standard Plates using Convolutional Neural Networks // International 
Conference on Image Analysis and Processing. 2015. С. 428–438. 
 
107 
 
11. OpenCV Developers. OpenCV Library Documentation. Електронний 
ресурс. 2024. URL: https://docs.opencv.org 
12. FastAPI Documentation. FastAPI Framework. Електронний ресурс. 2023. 
URL: https://fastapi.tiangolo.com 
13. Flask Developers. Flask Framework Documentation. Електронний ресурс. 
URL: https://flask.palletsprojects.com 
14. PostgreSQL Global Development Group. PostgreSQL Documentation. 
Електронний ресурс. 2024. URL: https://www.postgresql.org/docs 
15. SQLite Consortium. SQLite Documentation. Електронний ресурс. 2024. 
URL: https://www.sqlite.org/docs.html 
16. He K., Zhang X., Ren S., Sun J. Deep Residual Learning for Image 
Recognition // CVPR 2016. С. 770–778. 
17. Krizhevsky A., Sutskever I., Hinton G.E. ImageNet Classification with Deep 
Convolutional Neural Networks // NIPS 2012. С. 1097–1105. 
18. Simonyan K., Zisserman A. Very Deep Convolutional Networks for Large-
Scale Image Recognition. Електронний ресурс. 2014. URL: 
https://arxiv.org/abs/1409.1556 
19. Graves A., Fernández S., Schmidhuber J. Bidirectional LSTM Networks for 
OCR // Document Analysis and Recognition. 2009. С. 1–5. 
20. NVIDIA Corporation. Jetson Nano Developer Kit: Technical Guide. 
Електронний ресурс. URL: https://developer.nvidia.com/embedded/jetson-
nano 
21. Hikvision. IP Camera Specifications. Електронний ресурс. URL: 
https://www.hikvision.com 
22. Dahua Technology. Network Camera Product Catalog. Електронний ресурс. 
URL: https://www.dahuatech.com 
23. Axis Communications. AXIS Network Cameras Overview. Електронний 
ресурс. URL: https://www.axis.com 
24. Nedap Identification Systems. ANPR Access: Technical Documentation. 
Електронний ресурс. URL: https://www.nedapidentification.com 
108 
 
25. CAME S.p.A. Automatic Barriers Documentation. Електронний ресурс. 
URL: https://www.came.com 
26. Skidata AG. Parking Systems Overview. Електронний ресурс. URL: 
https://www.skidata.com 
27. OpenALPR Technology Inc. ALPR Software Documentation. Електронний 
ресурс. URL: https://www.openalpr.com 
28. Plate Recognizer. ALPR API Documentation. Електронний ресурс. URL: 
https://platerecognizer.com 
29. Kingma D.P., Ba J. Adam: A Method for Stochastic Optimization. 
Електронний ресурс. 2014. URL: https://arxiv.org/abs/1412.6980 
109
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
