Вбудована система GPS-трекінгу транспортних засобів з передачею даних через GSM/LTE

Костенко, Олексій Володимирович
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/10067
Full metadata record
DC Field	Value	Language
dc.contributor.advisor	Рудаков, Костянтин Сергійович	-
dc.contributor.author	Костенко, Олексій Володимирович	-
dc.date.accessioned	2026-10-22T12:06:05Z	-
dc.date.available	2026-10-22T12:06:05Z	-
dc.date.issued	2026-06	-
dc.identifier.uri	https://er.chdtu.edu.ua/handle/ChSTU/10067	-
dc.description.abstract	У кваліфікаційній роботі розроблено вбудовану систему GPS-трекінгу транспортних засобів із передачею даних через мережі GSM/GPRS. Проведено аналіз сучасних методів супутникової навігації, технологій стільникового зв’язку та наявних систем моніторингу транспорту. Обґрунтовано вибір апаратної платформи ESP32, GPS-модуля NEO-6M і GSM-модуля SIM800L. Розроблено структурну та принципову схеми пристрою, алгоритми обробки навігаційних даних формату NMEA, керування модемом і передавання координат на сервер за протоколом HTTP. Реалізовано серверну частину для приймання та збереження навігаційної інформації в локальній базі даних SQLite, а також вебінтерфейс для візуалізації місцезнаходження транспортного засобу та його маршрутів на карті Leaflet. Особливу увагу приділено фільтрації навігаційних даних, енергоефективності, надійності передавання інформації та забезпеченню її цілісності. Запропоновано адаптивну зміну частоти передавання координат залежно від швидкості й напрямку руху об’єкта для зменшення мережевого трафіку зі збереженням деталізації маршруту. Практичне значення роботи полягає у створенні доступного та гнучкого рішення для дистанційного моніторингу транспортних засобів із використанням локального сервера без залежності від сторонніх хмарних платформ.	uk_UA
dc.language.iso	uk	uk_UA
dc.subject	GPS-трекінг, моніторинг транспортних засобів, вбудована система, ESP32, GPS-модуль NEO-6M, GSM-модуль SIM800L, супутникова навігація, GSM/GPRS, GSM/LTE, протокол NMEA, HTTP, мікроконтролер, фільтрація навігаційних даних, SQLite, локальний сервер, Leaflet, візуалізація маршрутів, адаптивна передача даних, енергоефективність	uk_UA
dc.title	Вбудована система GPS-трекінгу транспортних засобів з передачею даних через GSM/LTE	uk_UA
dc.type	Bachelor Thesis	uk_UA
Appears in Collections:	123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи)
Files in This Item:
File	Description	Size	Format
Б_123_2026_Костенко.pdf Restricted Access		1.49 MB	Adobe PDF	View/Open Request a copy
Show simple item record
Extracted text
 
 
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ 
КОМП’ЮТЕРНИХ СИСТЕМ 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
освітнього ступеня «бакалавр» 
Вбудована система GPS-трекінгу транспортних засобів з 
на тему: 
передачею даних через GSM/LTE 
 
 
 
 
 
 Виконав здобувач вищої освіти 4 курсу, 
  групи СКС-2207 
  спеціальності 123 Комп’ютерна 
  інженерія 
  Олексій КОСТЕНКО 
  (ім’я та ПРІЗВИЩЕ) 
 Керівник Костянтин РУДАКОВ 
  (ім’я та ПРІЗВИЩЕ) 
 Рецензент  
  (ім’я та ПРІЗВИЩЕ) 
   
Захист дозволяю:   
зав. кафедри, д.т.н., професор   Валентина ЛУКАШЕНКО 
 (підпис)  (ім’я та ПРІЗВИЩЕ) 
 
 
 
 
 
 
Черкаси 2026 
 
 
 
ЗМІСТ 
ВСТУП ................................................................................................................. 4 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ ................................................... 6 
РОЗДІЛ 1 СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ 
ЗАВДАНЬ ............................................................................................................. 9 
1.1 Аналіз сучасних методів супутникової навігації та моніторингу 
об'єктів .............................................................................................................. 9 
1.2 Огляд стандартів передачі даних у стільникових мережах для систем 
IoT ................................................................................................................... 13 
1.3 Порівняльний аналіз існуючих аналогів систем моніторингу ........... 16 
1.4 Формулювання проблемних завдань дослідження .............................. 19 
ВИСНОВКИ ДО РОЗДІЛУ 1 ....................................................................... 20 
РОЗДІЛ 2 МЕТОДИ ТА МОДЕЛІ СТВОРЕННЯ КОМПОНЕНТІВ ТА ЇХ 
ДОСЛІДЖЕННЯ ............................................................................................... 23 
2.1 Системний аналіз об’єкта дослідження та обґрунтування вибору 
апаратної бази ................................................................................................ 23 
2.2 Розробка структурної та принципової схем вбудованої системи ...... 27 
2.3 Математичне моделювання процесів обробки та фільтрації 
навігаційних даних ........................................................................................ 33 
ВИСНОВКИ ДО РОЗДІЛУ 2 ....................................................................... 39 
РОЗДІЛ 3 ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ СИСТЕМИ ... 41 
3.1 Архітектура програмного забезпечення вбудованої системи та рівні 
ієрархії ПЗ ...................................................................................................... 41 
3.2 Алгоритми обробки навігаційних даних та керування GSM-модемом
 ......................................................................................................................... 43 
3.3 Реалізація серверної частини для збору, зберігання та візуалізації 
даних ............................................................................................................... 49 
2 
 
3.4 Аналіз надійності функціонування та механізми забезпечення 
цілісності даних ............................................................................................. 55 
3.5 Тестування системи та оцінка точності позиціонування об’єкта ...... 57 
ВИСНОВКИ ДО РОЗДІЛУ 3 ....................................................................... 60 
ВИСНОВКИ ....................................................................................................... 63 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................... 66 
3 
 
ВСТУП 
Стрімкий розвиток інформаційних технологій та глобальна 
цифровізація призвели до того, що системи дистанційного моніторингу та 
управління стали невід’ємною частиною сучасної транспортної 
логістики.[12]  В умовах динамічного ринку перевезень, безпека 
транспортних засобів, контроль витрат паливно-мастильних матеріалів та 
дотримання графіків руху об’єктів вимагають впровадження 
високотехнологічних рішень. Одним із найбільш ефективних інструментів 
для вирішення цих завдань є вбудовані системи GPS-трекінгу, які 
дозволяють отримувати точні координати об’єкта в реальному часі[3]  та 
передавати їх для подальшого аналізу. 
Актуальність розробки спеціалізованих систем моніторингу на базі 
мікроконтролерів зумовлена необхідністю створення бюджетних, але 
функціональних пристроїв, які можуть бути адаптовані під конкретні 
потреби малого бізнесу або приватних користувачів. Використання 
сучасних обчислювальних платформ, таких як ESP32, у поєднанні з 
технологіями стільникового зв’язку другого та четвертого поколінь 
(GSM/LTE)[2], відкриває широкі можливості для створення 
енергоефективних та автономних пристроїв. На відміну від універсальних 
комерційних трекерів, самостійно розроблена система дозволяє реалізувати 
гнучкі алгоритми обробки даних та забезпечити високий рівень 
конфіденційності шляхом передачі інформації на локальний сервер, що 
виключає залежність від сторонніх хмарних провайдерів та абонентської 
плати. 
Окрім суто інженерних завдань, розробка такої системи вимагає 
системного підходу до проектування програмно-апаратних комплексів, що 
включає вибір оптимальної елементної бази, розробку надійних протоколів 
передачі даних та створення інтерфейсів візуалізації. У даній 
кваліфікаційній роботі розглядається повний цикл створення вбудованої 
4 
 
системи: від системного аналізу предметної області до програмної реалізації 
локального сервера збору та відображення навігаційної інформації. 
 
5 
 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ 
Актуальність теми. Сучасний стан розвитку систем супутникової 
навігації та мобільних мереж зв'язку дозволяє створювати складні 
територіально розподілені системи моніторингу. Актуальність теми 
дослідження зумовлена необхідністю підвищення ефективності управління 
транспортними засобами та забезпечення їх збереженості. Існуючі на ринку 
України рішення часто характеризуються високою вартістю впровадження, 
закритістю програмного забезпечення та необхідністю постійних витрат на 
хмарні сервіси. Це створює попит на розробку альтернативних вбудованих 
систем, що базуються на принципах відкритої архітектури. Використання 
мікроконтролера ESP32, який поєднує в собі низьку вартість та високу 
продуктивність, дозволяє реалізувати складні алгоритми фільтрації 
координат та управління енергоспоживанням, що є критично важливим для 
автономних трекерів. Таким чином, розробка спеціалізованої системи GPS-
трекінгу з передачею даних на локальний сервер є актуальним науково-
прикладним завданням, спрямованим на оптимізацію витрат та підвищення 
технологічної незалежності користувачів. 
Зв’язок роботи з науковими програмами, планами, темами. Робота 
виконується відповідно до навчальних планів підготовки фахівців за 
спеціальністю 123 «Комп’ютерна інженерія» у Черкаському державному 
технологічному університеті. Тематика дослідження узгоджується з 
напрямами діяльності кафедри робототехніки та спеціалізованих 
комп’ютерних систем у сфері розробки інтелектуальних систем 
моніторингу та вбудованих обчислювальних засобів. 
Мета і завдання дослідження. Метою кваліфікаційної роботи є 
теоретичне обґрунтування, проектування та практична реалізація 
вбудованої системи GPS-трекінгу на базі мікроконтролера ESP32, яка 
забезпечує збір навігаційної інформації з супутників та її гарантовану 
6 
 
передачу через мережу GSM на локальний сервер для візуалізації 
маршрутів. 
Для досягнення поставленої мети визначено та вирішено такі завдання: 
1. Провести порівняльний аналіз сучасних методів супутникової 
навігації та стандартів бездротової передачі даних у системах 
моніторингу. 
2. Виконати системний аналіз об’єкта дослідження, визначити 
функціональні вимоги до вбудованої системи та обрати 
оптимальну апаратну базу. 
3. Розробити структурну та принципову схеми GPS-трекера, 
забезпечивши стабільне живлення компонентів та надійний 
зв'язок. 
4. Спроектувати та реалізувати вбудоване програмне забезпечення 
для мікроконтролера ESP32 з використанням алгоритмів обробки 
NMEA-повідомлень. 
5. Розробити серверне програмне забезпечення для прийому HTTP-
запитів, збереження координат у локальну базу даних SQLite[23] та 
створення веб-інтерфейсу на базі карти Leaflet. 
6. Провести експериментальне тестування прототипу в реальних 
умовах руху для оцінки точності позиціонування та затримок у 
мережі. 
Об’єкт дослідження – процес збору, обробки та дистанційної передачі 
навігаційних даних про стан рухомих об'єктів у реальному часі через 
інфраструктуру стільникового зв'язку. 
Предмет дослідження – методи та засоби побудови вбудованої 
системи на базі ESP32, алгоритми взаємодії з GPS та GSM модулями, а 
також програмні засоби локальної візуалізації треків. 
Методи дослідження. У роботі використано: методи теорії систем та 
системного аналізу - для обґрунтування структури системи; методи 
7 
 
проектування цифрових пристроїв - для розробки апаратної частини; методи 
об'єктно-орієнтованого програмування на мовах C++ (для ESP32) та Python 
(для сервера) - для створення програмного забезпечення; методи 
експериментальної перевірки - для валідації отриманих результатів. 
Наукова новизна одержаних результатів полягає у вдосконаленні 
алгоритму передачі даних шляхом впровадження адаптивної частоти 
відправки координат залежно від швидкості та напрямку руху об'єкта, що 
дозволяє зменшити обсяг мережевого трафіку при збереженні високої 
деталізації маршруту. 
Практичне значення одержаних результатів полягає у розробці 
завершеного прототипу спеціалізованої комп’ютерної системи, що може 
бути використана як база для побудови автономних комплексів моніторингу 
транспорту без використання сторонніх хмарних платформ.  
Апробація результатів роботи. Основні положення та технічні 
рішення кваліфікаційної роботи доповідались і обговорювались на щорічній 
студентській науково-практичній конференції ФІТІС ЧДТУ (Черкаси, 22-24 
квітня 2026 р.). 
Публікації. За матеріалами роботи опублікована теза доповідей: 
Вбудована система gps-трекінгу транспортних засобів з передачею даних 
через gsm/lte / О. В. Костенко, К. С. Рудаков // Збірник тез доповідей 
студентської науковопрактичної конференції ЧДТУ : 21-23 квітня 2026 р. 
[Електронний ресурс] / [упоряд. Мельник І.В.] ; Мво освіти і науки України, 
Черкас. держ. технол. унт. – Черкаси : ЧДТУ, 2026. 
Структура та обсяг роботи. Бакалаврська робота складається з вступу, 
трьох розділів основної частини, загальних висновків, списку використаних 
джерел та додатків. Повний обсяг пояснювальної записки становить 72 
сторінки, включаючи 18 рисунків, 6 таблиць та 35 найменувань у списку 
використаних джерел. 
 
8 
 
РОЗДІЛ 1 СТАН ПРЕДМЕТУ ДОСЛІДЖЕННЯ ТА ФОРМУВАННЯ 
ЗАВДАНЬ 
1.1 Аналіз сучасних методів супутникової навігації та 
моніторингу об'єктів 
Глобальні навігаційні супутникові системи (GNSS) пройшли 
тривалий шлях еволюції від закритих військових проектів до 
загальнодоступних сервісів, які стали основою для сучасної логістики, 
транспортної інфраструктури, геоінформаційних систем, навігації та систем 
безпеки. Сьогодні технології супутникового позиціонування активно 
застосовуються у транспортному моніторингу, аграрному секторі, 
робототехніці, телекомунікаціях, системах аварійного реагування та 
Інтернеті речей (IoT). Висока точність визначення координат, доступність 
обладнання та глобальне покриття сприяли широкому впровадженню GNSS 
у різноманітні сфери діяльності людини. 
Функціонування таких систем базується на сузір’ї штучних 
супутників Землі, що постійно випромінюють радіосигнали у L-діапазоні. 
Кожен супутник передає навігаційне повідомлення, яке містить інформацію 
про точний час передачі сигналу, параметри орбіти та службові дані. 
Приймач GNSS аналізує часову затримку між передачею та прийомом 
сигналу, на основі чого обчислюється відстань до супутника. Основним 
принципом, що лежить в основі розрахунку місцезнаходження, є метод 
трилатерації - математичний процес визначення координат шляхом 
знаходження точки перетину сфер, радіуси яких відповідають відстаням від 
приймача до декількох супутників. 
Для визначення двовимірних координат необхідно отримати сигнали 
щонайменше від трьох супутників, тоді як для повноцінного тривимірного 
позиціонування та корекції похибки внутрішнього годинника приймача 
використовується інформація мінімум від чотирьох супутників. Точність 
9 
 
позиціонування залежить від багатьох факторів, зокрема геометричного 
розташування супутників, атмосферних перешкод, багатопроменевого 
поширення сигналу, рівня шуму приймача та характеристик антени. 
На сьогодні найбільш поширеними глобальними супутниковими 
системами є GPS (США), GLONASS (Росія), Galileo (Європейський Союз) 
та BeiDou (Китай). Сучасні навігаційні модулі підтримують одночасну 
роботу з декількома супутниковими системами, що дозволяє підвищити 
точність позиціонування, скоротити час холодного старту та забезпечити 
стабільну роботу в умовах щільної міської забудови або складного рельєфу 
місцевості. 
Окрему роль у підвищенні точності супутникової навігації відіграють 
технології диференціальної корекції. До них належать DGPS, SBAS, RTK та 
PPP. Диференціальні методи використовують дані стаціонарних базових 
станцій для компенсації систематичних похибок супутникового сигналу. 
Наприклад, технологія RTK (Real-Time Kinematic) забезпечує сантиметрову 
точність визначення координат у реальному часі, що є критично важливим 
для геодезії, автономного транспорту та роботизованих систем. 
Системи супутникового моніторингу об’єктів поєднують GNSS-
приймачі із засобами передачі даних через GSM, LTE, NB-IoT або 
супутникові канали зв’язку. Типова архітектура таких систем включає 
навігаційний модуль, мікроконтролер або вбудований комп’ютер, модем 
бездротового зв’язку, систему живлення та серверну інфраструктуру для 
збору й аналізу телеметричних даних. Отримані координати, швидкість 
руху, напрямок, рівень заряду акумулятора та інші параметри передаються 
на сервер у режимі реального часу, де виконуються їх зберігання, 
візуалізація та подальша аналітична обробка. 
Сучасні системи моніторингу транспорту дозволяють реалізовувати 
широкий спектр функцій: контроль маршруту, геозонування, визначення 
простоїв, аналіз стилю водіння, облік витрат пального, виявлення 
10 
 
несанкціонованого переміщення та автоматичне формування звітів. Завдяки 
інтеграції з хмарними платформами та IoT-сервісами забезпечується 
централізований доступ до даних із великої кількості об’єктів незалежно від 
їх географічного розташування. 
Водночас існують певні обмеження супутникових навігаційних 
систем. Серед основних недоліків можна виділити залежність від прямої 
видимості супутників, зниження точності в тунелях, приміщеннях або 
густозабудованих районах, а також можливість впливу радіоперешкод і 
спуфінгу. Для підвищення надійності сучасні системи моніторингу часто 
комбінують GNSS із інерціальними датчиками, акселерометрами, 
гіроскопами та алгоритмами фільтрації, зокрема фільтром Калмана. 
 
 
Рис. 1.1. Спрощена схема взаємодії сегментів  
GNSS (космічного, керуючого та користувацького) 
 
На сьогодні у світі повноцінно функціонують кілька глобальних 
систем, кожна з яких має свої технічні особливості: 
11 
 
1. GPS (Global Positioning System, США)[14]: Найстаріша та найбільш 
стабільна система. Вона складається з сегменту супутників (мінімум 
24 активних одиниці), які розташовані на шести орбітальних 
площинах на висоті близько 20 200 км. Сучасні GPS-приймачі 
підтримують багатоканальність, що дозволяє одночасно відстежувати 
до 20 і більше супутників, суттєво підвищуючи точність 
позиціонування до 3–5 метрів у цивільному діапазоні. 
2. Galileo (Європейський Союз): Ця система є першим глобальним 
проектом, створеним під цивільним контролем. Вона забезпечує вищу 
точність порівняно з базовим GPS (до 1 метра для безкоштовних 
сервісів) та кращу доступність у високих широтах, що є критично 
важливим для північних регіонів Європи. 
3. BeiDou (Китай): Її відмінною рисою є можливість короткохвильової 
передачі повідомлень між користувачами, що фактично робить її не 
тільки навігаційною, а й комунікаційною системою. 
 
Таблиця 1.1 
Порівняння основних характеристик глобальних навігаційних 
супутникових систем 
Характеристика GPS Galileo BeiDou GLONASS 
Кількість 31 
24+ 35+ 24 
супутників (активних) 
Орбітальна висота 20 200 км 23 222 км 21 150 км 19 100 км 
Кількість площин 6 3 3 3 
Точність (цивільна) 3.5 – 7.8 м < 1 м 2.5 – 5 м 5 – 10 м 
Статус Глобальний Глобальний Глобальний Глобальний 
 
Процес збору даних у вбудованій системі починається з отримання 
сирих даних від GPS-модуля. На фізичному рівні це здійснюється через 
12 
 
послідовний інтерфейс UART. Основним промисловим стандартом 
передачі цієї інформації є протокол NMEA-0183[18] (National Marine 
Electronics Association). Це текстовий протокол, де кожне повідомлення 
починається з символу «$» і містить ідентифікатор типу даних. Наприклад, 
рядок $GPRMC є «мінімальним рекомендованим набором даних», що 
включає час, дату, широту, довготу, швидкість та магнітне схилення. 
Для бакалаврської роботи важливо підкреслити, що точність 
позиціонування залежить від багатьох факторів: 
− Геометричне розсіювання (DOP): Розташування супутників на 
небосхилі. Чим далі вони один від одного, тим вища точність. 
− Іоносферні затримки: Викривлення сигналу при проходженні через 
верхні шари атмосфери. 
− Ефект багатопроменевості: Відбиття сигналу від будівель або дерев, 
що створює хибні затримки (особливо актуально для міських умов). 
Системи моніторингу, що проектуються сьогодні, повинні 
використовувати багатосистемні модулі (GNSS-модулі), які здатні 
одночасно працювати з GPS, Galileo та BeiDou. Це дозволяє в рази 
збільшити кількість видимих супутників у складних умовах (вузькі вулиці, 
лісова місцевість) та забезпечити безперервність трекінгу. 
1.2 Огляд стандартів передачі даних у стільникових мережах для 
систем IoT 
Ефективність функціонування системи GPS-моніторингу 
безпосередньо залежить від надійності каналу зв’язку, через який 
координати передаються від вбудованого модуля на сервер. У сучасних 
інженерних рішеннях для передачі невеликих пакетів даних на великі 
відстані найчастіше використовується інфраструктура мереж стільникового 
зв'язку[2]. Вибір конкретного стандарту (2G, 3G, 4G або спеціалізованих IoT-
протоколів) визначає енергоспоживання пристрою, стабільність зв’язку в 
13 
 
умовах слабкого сигналу та загальну вартість експлуатації системи. 
1.2.1. Технологія GSM/GPRS (2G) як базовий канал передачі Незважаючи 
на активне впровадження мереж п'ятого покоління, стандарт GSM (Global 
System for Mobile Communications) залишається фундаментом для 
бюджетних систем моніторингу в Україні. Для передачі цифрової 
інформації всередині GSM використовується технологія GPRS (General 
Packet Radio Service)[11]. 
● Принцип комутації пакетів: На відміну від голосового зв'язку, де лінія 
резервується під одного користувача, GPRS використовує вільні 
часові слоти для передачі даних невеликими порціями (пакетами). Це 
дозволяє трекеру бути постійно підключеним до мережі («always-
on»), але оплачувати лише фактично переданий обсяг трафіку. 
● Покриття та проникна здатність: Радіосигнали частотного діапазону 
900 МГц мають здатність огинати перешкоди та проникати всередину 
будівель краще, ніж високочастотні сигнали 4G/5G, що є критичним 
для транспортних засобів, які можуть перебувати в критих ангарах або 
щільній забудові. 
1.2.2. Стандарт LTE та спеціалізовані рішення для Інтернету речей (NB-
IoT/LTE-M) Розвиток мереж четвертого покоління (LTE) приніс нові 
можливості для вбудованих систем. Однак стандартний LTE Cat 4, що 
використовується в смартфонах, є занадто енерговитратним для автономних 
пристроїв. Тому в рамках 4G були розроблені специфікації для IoT: 
● LTE-M (Machine Type Communication): Забезпечує достатню 
пропускну здатність для передачі навіть голосових повідомлень, але 
головна його перевага - підтримка мобільності. Пристрій може 
«переходити» від однієї базової станції до іншої без розриву з'єднання 
на швидкості до 100 км/год, що ідеально підходить для GPS-трекерів. 
● NB-IoT (Narrowband IoT): Цей стандарт призначений для 
стаціонарних датчиків або об'єктів, що рухаються повільно. Він має 
14 
 
надзвичайно низьке енергоспоживання, що дозволяє пристрою 
працювати від одного акумулятора роками, проте затримки в передачі 
даних можуть бути вищими, ніж у LTE-M. 
 
 
 
Рис. 1.2. Структурна схема передачі даних від трекера  
через стільникову мережу до локального сервера 
 
1.2.3. Порівняльний аналіз протоколів обміну даними (HTTP vs MQTT[15]) 
Окрім вибору фізичного каналу зв'язку, важливо визначити програмний 
протокол, за яким ESP32 буде спілкуватися з сервером. 
1. HTTP (HyperText Transfer Protocol): Найбільш поширений протокол. 
Кожна передача координат оформлюється як POST-запит до сервера. 
Перевагою є простота реалізації на боці сервера (Flask/Django) та 
легке проходження через міжмережеві екрани. Недолік - великий 
обсяг службових заголовків, що збільшує трафік. 
2. MQTT (Message Queuing Telemetry Transport): Легковажний протокол, 
що працює за моделлю «видавець-підписник». Він ідеально підходить 
для IoT, оскільки пакет даних має мінімальний розмір (від 2 байт), що 
суттєво економить заряд батареї та кошти на SIM-карті. 
 
15 
 
Таблиця 1.2 
Технічні характеристики стандартів зв'язку для вбудованих систем 
моніторингу 
Параметр Професійні Охоронні Проектована 
порівняння (Teltonika) (StarLine) система 
Повна (Open 
Відкритість коду Закритий Закритий 
Source) 
Хмара 
Сервер зберігання Платна хмара Локальний ПК 
виробника 
Висока (дані 
Конфіденційність Середня Низька 
вдома) 
Гнучкість Через Програмна 
Відсутня 
налаштувань конфігуратор (C++/Python) 
 
У даній кваліфікаційній роботі, враховуючи вимогу простоти 
реалізації, обрано комбінацію GSM/GPRS як фізичного рівня та HTTP як 
прикладного рівня. Це дозволяє забезпечити максимальне покриття на 
території України та спростити розробку локального сервера на базі мови 
Python. 
1.3 Порівняльний аналіз існуючих аналогів систем моніторингу 
Для об’єктивної оцінки розроблюваної системи необхідно провести 
детальний аналіз сучасного ринку засобів GPS-моніторингу. На 
сьогоднішній день рішення для відстеження транспорту можна розділити на 
дві великі категорії: професійні логістичні комплекси та споживчі (або 
охоронні) трекери. Кожне з цих рішень має свої архітектурні особливості, 
переваги та критичні недоліки в контексті використання індивідуальними 
користувачами або малим бізнесом. 
1.3.1. Професійні логістичні системи (на прикладі Teltonika та Ruptela) 
16 
 
Литовські компанії Teltonika та Ruptela є лідерами європейського ринку 
вбудованих рішень для телематики. Їхні пристрої, такі як серія Teltonika 
FMB920, широко використовуються в Україні для контролю великих 
автопарків. 
● Переваги: Висока надійність, підтримка протоколів CAN-шини для 
зчитування даних про стан двигуна, вбудовані акселерометри для 
аналізу стилю водіння та підтримка Bluetooth-датчиків (наприклад, 
датчиків рівня палива). 
● Недоліки: Висока вартість апаратної частини (від 50$ за одиницю) та 
складність налаштування, що потребує спеціалізованого ПЗ. Крім 
того, такі пристрої орієнтовані на роботу з корпоративними хмарними 
сервісами (Wialon тощо), які передбачають щомісячну абонентську 
плату за кожен підключений об'єкт. 
1.3.2. Споживчі та охоронні системи (на прикладі StarLine та Pandora) 
Ці системи часто інтегруються безпосередньо в автосигналізації. Вони 
забезпечують не лише трекінг, а й дистанційне керування функціями 
автомобіля. 
● Переваги: Зручні мобільні додатки, інтеграція з охоронними 
функціями, наявність вбудованих акумуляторів для роботи при 
відключенні основного живлення. 
● Недоліки: Повна закритість екосистеми. Користувач не має доступу 
до «сирих» даних і не може змінити сервер призначення. Уся 
інформація зберігається на серверах виробника, що створює певні 
ризики щодо конфіденційності та стабільності роботи системи в разі 
виникнення технічних проблем у постачальника послуг. 
1.3.3. DIY-рішення та Open Source проекти 
Існує категорія розробок на базі платформ Arduino або Raspberry Pi. 
Вони найбільш близькі до об’єкта даної кваліфікаційної роботи, проте часто 
мають низьку надійність через використання невідповідних компонентів 
17 
 
або відсутність механізмів обробки помилок зв'язку. 
 
Таблиця 1.3 
Порівняльний аналіз технічних та експлуатаційних характеристик 
систем моніторингу 
Споживчі 
Teltonika Проектована 
Характеристика трекери 
FMB920 система (ESP32) 
(StarLine) 
Закрита Закрита Відкрита 
Архітектура ПЗ 
(Пропрієтарна) (Хмарна) (Вбудована) 
Хмарні сервіси Сервери Локальний 
Зберігання даних 
(платні) виробника сервер (власний) 
Вартість Висока (>1500 Низька (<600 
Середня/Висока 
обладнання грн) грн) 
Можливість Обмежена Повна (вихідний 
Відсутня 
модифікації (конфігуратор) код) 
Складність Потребує Проста (Plug & 
Складна 
монтажу спеціаліста Play) 
 
 
Рис. 1.3. Діаграма порівняння вартості експлуатації  
систем на проміжку 12 місяців 
 
18 
 
Аналіз аналогів показує, що для сегмента користувачів, яким потрібен 
базовий моніторинг без абонентської плати та з повним контролем над 
власними даними, розробка вбудованої системи на базі ESP32 є найбільш 
раціональним рішенням. Вона дозволяє поєднати низьку вартість 
компонентів з можливістю реалізації саме тих функцій, які необхідні для 
конкретної задачі, уникаючи надлишкового функціоналу комерційних 
систем 
1.4 Формулювання проблемних завдань дослідження 
На основі проведеного аналізу сучасного стану систем супутникової 
навігації (підрозділ 1.1), огляду стандартів бездротового зв’язку (підрозділ 
1.2) та порівняння з існуючими аналогами (підрозділ 1.3), стає очевидним 
ряд технічних і системних проблем, які потребують вирішення при розробці 
власної вбудованої системи GPS-трекінгу. 
1.4.1. Проблема забезпечення автономності та енергоефективності 
Більшість комерційних трекерів споживають значну кількість енергії через 
постійну роботу GSM-модуля. Для вбудованої системи на базі ESP32 
критично важливо реалізувати алгоритм інтелектуального управління 
живленням. Це передбачає переведення мікроконтролера та периферійних 
модулів у режими глибокого сну (Deep Sleep) у періоди, коли транспортний 
засіб не рухається. Визначення стану руху повинно базуватися на аналізі 
навігаційних даних або використанні додаткових датчиків, що дозволить 
подовжити час роботи пристрою від резервного акумулятора. 
1.4.2. Оптимізація передачі даних у зонах з нестабільним покриттям У 
процесі руху об’єкт може потрапляти в зони з відсутнім або слабким 
сигналом стільникового зв'язку (GPRS/LTE). Проблемою є ризик втрати 
навігаційних точок (координат) за ці періоди. В рамках роботи необхідно 
передбачити механізм локального буферизації даних у пам'яті ESP32 або на 
зовнішньому носії, з подальшою передачею всього накопиченого масиву 
19 
 
після відновлення з’єднання з сервером. 
1.4.3. Конфіденційність та незалежність від хмарних сервісів Використання 
сторонніх платформ для моніторингу несе ризики витоку інформації про 
переміщення об'єктів та залежність від стабільності роботи цих сервісів. 
Проблемним завданням є розгортання власного локального сервера, який би 
забезпечував: 
● Прийом даних за відкритим протоколом HTTP; 
● Збереження історії в локальну базу даних з можливістю швидкої 
вибірки; 
● Візуалізацію треків без передачі координат стороннім API 
(використання OpenStreetMap). 
 
 
Рис. 1.4. Діаграма декомпозиції завдань розробки 
вбудованої системи 
 
ВИСНОВКИ ДО РОЗДІЛУ 1 
У першому розділі було проведено всебічний науково-технічний 
аналіз предметної області, що стосується побудови вбудованих систем 
супутникового моніторингу транспортних засобів. На основі систематизації 
20 
 
опрацьованої літератури, патентного пошуку та аналізу сучасних ринкових 
рішень, можна сформулювати розширені висновки: 
1. Актуальність та системний аналіз проблеми: Доведено, що в умовах 
цифрової трансформації логістичної галузі України, системи GPS-
моніторингу перестають бути просто засобом визначення координат, 
а перетворюються на комплексні інструменти автоматизації бізнес-
процесів. Аналіз існуючих комерційних платформ виявив тенденцію 
до їх здорожчання через використання пропрієтарного програмного 
забезпечення та хмарних сервісів з підпискою. Це обґрунтовує 
необхідність розробки відкритої, бюджетної та гнучкої системи на 
базі доступних мікропроцесорних компонентів, яка забезпечувала б 
високу автономність та конфіденційність даних. 
2. Обґрунтування вибору навігаційних та комунікаційних стандартів: У 
ході порівняльного аналізу глобальних навігаційних супутникових 
систем (GNSS) встановлено, що для цивільного сектору найбільш 
стабільним та точним залишається американський стандарт GPS у 
поєднанні з європейським Galileo. Дослідження методів передачі 
даних показало, що незважаючи на розвиток 4G/5G, мережі стандарту 
GSM/GPRS (2G) залишаються найбільш доцільними для даного 
проекту. Це обумовлено їх максимальною географічною площею 
покриття, низькою вартістю передачі малих пакетів даних 
(координат) та меншим енергоспоживанням модемів у порівнянні з 
високошвидкісними стандартами. 
3. Критеріальний вибір апаратної платформи: Було проведено глибоке 
порівняння сучасних архітектур мікроконтролерів, включаючи 
сімейства STM32, AVR та ESP32. За результатами аналізу, для 
реалізації проекту було обрано систему на кристалі (SoC) ESP32. 
Основними критеріями вибору стали: 
○ Двоядерна архітектура: можливість фізичного розподілу 
21 
 
завдань (паралельне виконання обробки GPS-сигналу та 
підтримки мережевого стеку), що критично для систем 
реального часу. 
○ Енергоефективність: наявність розширених режимів глибокого 
сну (Deep Sleep), що дозволяє пристрою працювати від 
акумулятора транспортного засобу місяцями без підзарядки. 
○ Об’єм пам’яті та периферія: достатня кількість апаратних 
UART-інтерфейсів для одночасного підключення GPS та GSM 
модулів без використання програмної емуляції, яка є 
нестабільною. 
4. Формулювання комплексу технічних та експлуатаційних вимог: На 
основі проведеного аналізу було сформовано детальний перелік вимог 
до розроблюваної системи, що лягли в основу наступних розділів 
проекту: 
○ Реалізація протоколу обміну даними, що мінімізує об’єм 
трафіку (передача у форматі HTTP GET/POST). 
○ Створення механізму гарантованої доставки повідомлень у 
зонах з нестабільним зв'язком за допомогою локального 
буферування. 
○ Розробка серверної частини з відкритим вихідним кодом для 
забезпечення повного контролю власника над навігаційною 
інформацією. 
Проведені теоретичні дослідження першого розділу є фундаментом 
для подальшого конструкторського проектування та програмної реалізації 
системи, що підтверджує наукову обґрунтованість обраного напрямку 
розробки. 
 
22 
 
РОЗДІЛ 2 МЕТОДИ ТА МОДЕЛІ СТВОРЕННЯ КОМПОНЕНТІВ ТА 
ЇХ ДОСЛІДЖЕННЯ 
2.1 Системний аналіз об’єкта дослідження та обґрунтування 
вибору апаратної бази 
Процес створення спеціалізованої вбудованої системи GPS-трекінгу 
починається з детального аналізу вимог до обчислювальних потужностей, 
енергоспоживання та комунікаційних можливостей. Відповідно до 
методичних рекомендацій, необхідно наповнити принципи системного 
аналізу конкретним змістом, виходячи з предметної області. Системний 
підхід вимагає розгляду трекера не просто як набору мікросхем, а як 
комплексної телематичної одиниці, що функціонує в умовах динамічного 
зовнішнього середовища, дестабілізуючих факторів бортової мережі 
автомобіля та нестабільного покриття стільникових мереж зв'язку. 
Об’єктом проектування є вбудований програмно-технічний комплекс, 
що повинен працювати в режимі реального часу. При декомпозиції 
загальної структури об'єкта дослідження було визначено три ключові 
підсистеми: підсистема первинного збору навігаційних даних, центральний 
обчислювальний блок координації та фільтрації, а також підсистема 
трансляції телеметричної інформації на віддалений сервер. 
Основними критеріями вибору апаратної платформи є: 
● Продуктивність: здатність одночасно обробляти навігаційні пакети 
NMEA за допомогою синтаксичного аналізу (парсингу) текстових 
рядків на одному обчислювальному ядрі та підтримувати стек 
протоколів TCP/IP для передачі даних через AT-команди на іншому 
ядрі без виникнення критичних затримок виконання потоків (tasks). 
● Енергоефективність: наявність режимів глибокого сну (Deep Sleep) 
для мінімізації споживання струму під час стоянки транспортного 
засобу, що запобігає розряду штатного автомобільного акумулятора. 
23 
 
● Компактність: можливість інтеграції системи та трасування 
друкованої плати мінімальних габаритів для прихованого й 
безпечного розміщення комплексу в обмеженому просторі 
транспортного засобу. 
Для реалізації поставлених завдань у даній роботі обрано платформу 
ESP32 DevKit V1. Цей мікроконтролер побудований на базі двоядерного 32-
бітного процесора Xtensa® Dual-Core LX6, що працює на тактовій частоті 
до 240 МГц. Обчислювальне ядро забезпечує продуктивність на рівні до 600 
DMIPS, що дозволяє реалізовувати складні математичні алгоритми 
цифрової фільтрації геокоординат. 
Наявність великої кількості апаратних периферійних інтерфейсів 
(UART, SPI, I2C) дозволяє легко інтегрувати навігаційні та комунікаційні 
модулі на фізичному рівні без застосування ресурсномісткої програмної 
емуляції портів. Особливою перевагою обраного мікроконтролера є 
наявність вбудованих контролерів бездротового зв'язку Wi-Fi (802.11 b/g/n) 
та Bluetooth (v4.2 BR/EDR і BLE). У межах даного проекту це може бути 
використано для бездротової локальної діагностики пристрою, зчитування 
логів та оновлення прошивки «по повітрю» (OTA) без необхідності 
демонтажу трекера та його прямого підключення до персонального 
комп'ютера. 
Для забезпечення навігаційної функції обрано модуль u-blox NEO-6M. 
Цей модуль характеризується високою динамічною чутливістю на рівні -161 
дБм під час відстеження супутників, що дозволяє впевнено приймати слабкі 
радіосигнали в умовах щільної багатоповерхової міської забудови. Модуль 
підтримує швидкий час «гарячого» старту (менше 1 секунди) завдяки 
архітектурі апаратного 50-канального позиціонування. 
Взаємодія між навігаційним приймачем та обчислювальною 
платформою ESP32 здійснюється через послідовний апаратний інтерфейс 
24 
 
UART1 на швидкості 9600 бод. Модуль штатно оснащений виносною 
активною керамічною антеною із вбудованим малошумним підсилювачем 
(LNA) та додатковою енергонезалежною пам'яттю (EEPROM) у поєднанні з 
літієвою батареєю резервного живлення. Наявність цієї резервної 
підсистеми є критично важливою для стабільної роботи, оскільки вона 
дозволяє зберігати альманах та ефемерідні дані супутників після 
короткочасних вимкнень основного бортового живлення автомобіля, значно 
скорочуючи час до першої фіксації координат (TTFF). 
 
 
Рис. 2.1. Внутрішня архітектура мікроконтролера  
ESP32 та схема розподілу периферійних інтерфейсів 
 
Комунікаційна складова вбудованої системи реалізована на базі 
стільникового GSM-модуля SIM800L. Вибір цього компонента 
обумовлений його низькою собівартістю, доступністю на ринку та повною 
апаратною підтримкою технології пакетної передачі даних GPRS класу 12. 
Інтегрований модем функціонує у чотирьох стандартних діапазонах частот 
(850/900/1800/1900 МГц), що гарантує його стабільну сумісність з усіма 
25 
 
операторами мобільного зв'язку, які діють на території України. Взаємодія 
з мікроконтролером організована через порт UART2 на швидкості 115200 
бод за допомогою стандартних текстових AT-команд. 
Специфіка функціонування модуля SIM800L полягає в тому, що під 
час сеансів зв'язку, реєстрації в мережі стільникових базових станцій та 
безпосередньої відправки GPRS-пакетів споживання струму має різко 
виражений імпульсний характер (пікові значення можуть сягати до 2 А). 
Для компенсації цих просідань струму та забезпечення безперебійної 
роботи системи живлення пристрою, схемотехнічним рішенням 
передбачено обов'язкове використання низькоімпедансних (Low-ESR) 
потужних електролітичних конденсаторів великої ємності (не менше 1000 
мкФ) у безпосередній близькості до виводів живлення модема. Також 
застосовано високоефективний імпульсний DC-DC знижувальний 
стабілізатор напруги з високим коефіцієнтом корисної дії (ККД), який 
забезпечує перетворення вхідної напруги бортової мережі автомобіля до 
стабільних 4.0 В, необхідних для коректної роботи радіотракту модема. 
 
Таблиця 2.1 
Порівняння технічних характеристик ESP32 з альтернативними 
мікроконтролерами (Arduino Nano, STM32F103) 
Arduino Nano STM32F103 ESP32 
Характеристика 
(ATmega328) (Cortex-M3) (LX6) 
Розрядність 8 біт 32 біти 32 біти 
Тактова частота 16 МГц 72 МГц 240 МГц 
Об'єм Flash-пам'яті 32 КБ 64/128 КБ 4 МБ 
Об'єм ОЗП (RAM) 2 КБ 20 КБ 520 КБ 
Вбудований Wi-Fi / 
Відсутній Відсутній 
бездротовий зв'язок Bluetooth 
Напруга живлення 5 В 3.3 В 3.3 В 
26 
 
2.2 Розробка структурної та принципової схем вбудованої 
системи 
Проєктування архітектури вбудованої системи GPS-трекінгу на базі 
ESP32 вимагає чіткого визначення інформаційних та енергетичних зв’язків 
між основними функціональними блоками. Відповідно до системного 
аналізу, проведеного у попередньому підрозділі, архітектура повинна 
забезпечувати надійне зчитування навігаційних даних, їх тимчасове 
зберігання та передачу через стільникову мережу за умови мінімальних 
втрат енергії. 
2.2.1 Структурна організація системи 
На рівні структурної схеми пристрій можна розділити на чотири 
функціонально завершені підсистеми, які забезпечують повний цикл збору, 
обробки та передачі телеметричної інформації. Такий модульний підхід до 
проектування дозволяє не лише спростити налагодження окремих вузлів, а 
й забезпечує можливість легкої модернізації апаратної частини без зміни 
загальної архітектури програмного забезпечення. 
1. Центральний обчислювальний модуль (ESP32): Виконує роль 
інтелектуального ядра (координатора) всієї системи. Його 
функціональність включає ініціалізацію периферійних модулів при 
старті, зчитування навігаційних даних через інтерфейс UART, їх 
математичну фільтрацію, формування пакетів даних у форматі 
JSON/HTTP та керування GSM-модемом за допомогою послідовності 
AT-команд. Використання двоядерної архітектури дозволяє розділити 
завдання обробки GPS-сигналу та підтримку мережевого стеку, що 
забезпечує безперервність моніторингу навіть під час виконання 
мережевих операцій. 
2. Навігаційна підсистема (NEO-6M): Постійно отримує сигнали з 
навігаційних супутників (GPS/GLONASS) через виносну керамічну 
27 
 
антену. Модуль виконує обчислення поточних координат, швидкості, 
висоти та часу, видаючи готові дані у вигляді текстових речень стандарту 
NMEA-0183 (зокрема $GPRMC, $GPGGA). Завдяки наявності 
енергонезалежної пам'яті (EEPROM), модуль зберігає дані альманаху, що 
критично скорочує час повторного «холодного» старту після вимкнення 
живлення. 
3. Комунікаційна підсистема (SIM800L): Відповідає за вихід в мережу 
Інтернет та передачу сформованих пакетів даних на сервер. Модуль 
забезпечує підтримку GPRS-з’єднання класу 12, що є найбільш 
ефективним для передачі невеликих обсягів телеметрії. Ця підсистема 
реалізує протокол прикладного рівня HTTP, використовуючи внутрішній 
TCP/IP стек для формування запитів до API-сервера. Модем працює в 
режимі «always-on», забезпечуючи постійний зв’язок із стільниковими 
вишками. 
4. Підсистема живлення: Є критично важливим енергетичним вузлом, який 
перетворює напругу бортової мережі автомобіля (9–24 В) у стабільні 
рівні напруги для роботи компонентів. Вона забезпечує: 
○ Стабілізовані 3.3 В: для живлення мікроконтролера ESP32 та 
навігаційного модуля NEO-6M. 
○ Стабілізовані 4.0 В: через окремий високоефективний DC-DC 
перетворювач для GSM-модуля SIM800L. 
5. Враховуючи імпульсний характер споживання струму модемом (пікові 
навантаження до 2 А під час передачі даних), підсистема включає 
ланцюги фільтрації на основі електролітичних конденсаторів великої 
ємності та низькоімпедансних керамічних конденсаторів для мінімізації 
пульсацій напруги та запобігання «зависанням» системи при просіданні 
напруги бортової мережі. 
28 
 
 
Рис. 2.2. Структурна схема вбудованої системи  
GPS-трекінгу з відображенням основних вузлів та  
інтерфейсів взаємодії 
 
2.2.2 Організація міжмодульної взаємодії через інтерфейс UART 
Для забезпечення високошвидкісного, надійного та завадостійкого 
обміну інформаційними потоками між центральним мікроконтролером 
системи та периферійними модулями (навігаційним та комунікаційним) 
було обрано асинхронний послідовний інтерфейс UART (Universal 
Asynchronous Receiver-Transmitter). Вибір даного інтерфейсу обумовлений 
його простотою реалізації на фізичному рівні, відсутністю необхідності 
трансляції тактового сигналу (що зменшує кількість провідників у шлейфах 
та знижує рівень випромінюваних електромагнітних завад) і повною 
апаратною підтримкою з боку всіх інтегрованих компонентів. 
На фізичному рівні інтерфейс UART використовує дві незалежні 
односпрямовані лінії передачі даних: лінію передачі даних $\text{TX}$ 
(Transmit Data) та лінію прийому даних $\text{RX}$ (Receive Data), що 
дозволяє організувати повнодуплексний (Full-Duplex) режим роботи 
29 
 
підсистеми. Оскільки архітектура системи на кристалі ESP32 містить три 
незалежні апаратні контролери UART (UART0, UART1 та UART2), це 
повністю усуває необхідність програмної емуляції послідовних портів 
(Software Serial), яка є критично нестабільною в багатозадачних 
операційних системах реального часу та призводить до надлишкового 
навантаження на обчислювальні ядра процесора. Апаратна реалізація 
дозволяє налаштувати індивідуальні параметри кадру, обсяги внутрішніх 
FIFO-буферів та механізми прямими перериваннями для кожного каналу 
зв'язку окремо. 
В межах проектованого пристрою розподіл апаратних ресурсів UART 
організовано наступним чином: 
● Канал зв'язку з навігаційною підсистемою (UART1): Даний порт 
призначений для зчитування безперервного потоку навігаційних 
речень від GPS-приймача u-blox NEO-6M. На фізичному рівні для 
цього задіяні виводи мікроконтролера GPIO 16 (як RX1) та GPIO 17 
(як TX1). Швидкість асинхронного обміну для UART1 жорстко 
встановлена на базовому рівні 9600 бод (біт/с), що є заводським 
стандартом за замовчуванням для більшості GNSS-приймачів 
геопросторових даних. Формат інформаційного кадру сконфігуровано 
за класичною схемою: 1 стартовий біт, 8 біт даних, відсутність біта 
парності (None) та 1 стоповий біт (конфігурація 8N1). Вибір порівняно 
низької швидкості (9600 бод) є інженерно обґрунтованим, оскільки 
темп оновлення даних модулем NEO-6M становить 1 Гц (один пакет 
речень NMEA на секунду). Така швидкість мінімізує ймовірність 
виникнення помилок кадрування (Framing Errors) при проходженні 
сигналу по провідниках в умовах високого рівня високочастотних 
імпульсних наведень від розташованого поруч GSM-модема. 
● Канал зв'язку з комунікаційною підсистемою (UART2): Даний 
апаратний порт виділений виключно для двостороннього обміну 
30 
 
даними та текстовими керуючими командами з GSM/GPRS-модемом 
SIM800L. Фізичне підключення здійснено до виводів 
мікроконтролера GPIO 18 (як RX2) та GPIO 19 (як TX2). На відміну 
від навігаційного каналу, швидкість обміну для UART2 встановлена 
на максимально стабільному для даного модема рівні - 115200 бод. 
Формат кадру також відповідає стандарту 8N1. Висока швидкість 
(115200 бод) є критично необхідною для прискорення трансляції 
масивів даних на віддалений REST-сервер, зменшення часу 
перебування мікроконтролера в активному (енерговитратному) стані 
під час передачі великих пакетів або вивантаження локального 
EEPROM-буфера, а також для оперативного зчитування відповідей 
від модема на надіслані AT-команди. 
Для запобігання втрати вхідних байтів (буферного переповнення) 
через асинхронність процесів, обробка даних на рівні програмних драйверів 
ESP32 реалізована за допомогою механізму переривань (Interrupt Service 
Routine - ISR) та кільцевих буферів (Ring Buffers). Коли на лінію RX 
надходить черговий байт даних, апаратний контролер UART генерує 
внутрішнє переривання. Драйвер миттєво зчитує байт із 128-байтного 
апаратного FIFO-клієнта мікроконтролера та переміщує його в програмний 
кільцевий буфер у оперативній пам'яті (RAM) обсягом 256 байт для UART1 
та 512 байт для UART2. 
Така дворівнева схема буферизації дозволяє ізолювати фізичний 
процес прийому байтів від прикладних завдань FreeRTOS. Завдання 
Task_GPS та Task_GSM можуть асинхронно забирати дані з кільцевих 
буферів та виконувати їх конкатенацію й парсинг тоді, коли обчислювальне 
ядро звільняється від виконання інших пріоритетних операцій, що 
забезпечує максимальну детермінованість та стабільність функціонування 
всієї системи реального часу. 
 
31 
 
2.2.3 Проєктування підсистеми стабілізації живлення 
Особливістю використання модуля SIM800L є його високе імпульсне 
споживання струму (до 2А) у моменти реєстрації в мережі або передачі 
даних. Оскільки бортова мережа автомобіля або акумулятор видають 
напругу, що перевищує допустимі межі модулів, необхідно 
використовувати імпульсні знижувальні перетворювачі (Buck Converters) 
типу LM2596. 
● Перша лінія (3.3В): живить ESP32 та NEO-6M. Потребує стабілізації з 
низьким рівнем шумів. 
● Друга лінія (4.0В): призначена виключно для SIM800L. Важливо 
забезпечити велику ємність конденсаторів (не менше 1000 мкФ) 
безпосередньо біля виводів живлення модуля для компенсації 
просідань напруги. 
 
 
Рис. 2.3. Принципова електрична схема підключення  
модулів до ESP32 із зазначенням номерів пінів та елементів кола живлення 
 
32 
 
Таблиця 2.2 
Розподіл ресурсів введення-виведення (I/O) мікроконтролера ESP32 
для підключення периферії 
Пін ESP32 Призначення Назва сигналу Напрям (Direction) 
GPIO 16 RX (UART1) GPS_TX Вхід (Input) 
GPIO 17 TX (UART1) GPS_RX Вихід (Output) 
GPIO 18 RX (UART2) GSM_TX Вхід (Input) 
GPIO 19 TX (UART2) GSM_RX Вихід (Output) 
GPIO 4 Enable GSM_PWR_KEY Вихід (Output) 
GPIO 32 ADC BAT_VOLTAGE Аналоговий вхід 
 
Розроблена архітектура дозволяє не лише виконувати базову функцію 
трекінгу, а й закладає можливості для подальшого розширення системи 
(наприклад, підключення датчика рівня палива або тривожної кнопки), що 
відповідає вимогам гнучкості та модульності спеціалізованих 
комп’ютерних систем. 
2.3 Математичне моделювання процесів обробки та фільтрації 
навігаційних даних 
Якість функціонування системи GPS-трекінгу визначається не лише 
апаратною стабільністю та завадостійкістю електронних компонентів, а й 
ефективністю впроваджених алгоритмів цифрової обробки отриманої 
координатної інформації. Навігаційні дані, що надходять від супутникового 
модуля NEO-6M у безперервному режимі, мають дискретний характер і 
містять у собі комплексні похибки, які за своєю природою поділяються на 
детерміновані (систематичні) та випадкові (стохастичні). 
33 
 
Систематичні похибки здебільшого зумовлені сукупністю космічних та 
геофізичних факторів: 
● Іоносферними та тропосферними затримками: викривлення та 
спотворення фазової швидкості поширення радіохвиль $L1$-
діагузону ($1575.42\text{ МГц}$) при проходженні крізь неоднорідні 
шари атмосфери Землі. 
● Ефемеридними похибками: незначними розходженнями між 
реальними координатами супутників на орбіті та їх розрахунковими 
значеннями, що транслюються у складі навігаційного повідомлення. 
● Релятивістськими ефектами: зміщенням часових шкал через 
різницю гравітаційних потенціалів та високих швидкостей руху 
космічних апаратів. 
Випадкові похибки мають стохастичну структуру і генеруються 
безпосередньо у користувацькому сегменті: 
● Ефектом багатопроменевості (Multipath effect): багаторазовим 
відбиттям радіосигналу від поверхонь споруд, залізобетонних 
конструкцій, елементів рельєфу або щільної міської забудови. Це 
призводить до інтерференції хвиль і хибного збільшення 
розрахункового часу проходження сигналу від супутника до антени 
приймача. 
● Власними тепловими шумами приймального тракту: флуктуаціями 
у напівпровідниковій структурі вхідного малошумного підсилювача 
(LNA) модуля NEO-6M. 
Для отримання достовірного, згладженого та геометрично коректного 
маршруту транспортного засобу в умовах динамічного руху виникає 
необхідність застосування математичного моделювання процесів фільтрації 
безпосередньо на етапі обробки даних мікроконтролером. 
З погляду математичного опису, сирий потік геокоординат від GPS-
приймача є дискретною послідовністю вимірювань, де кожна реальна 
34 
 
координата (істинне положення об'єкта) суперпонується з адитивним білим 
гаусовим шумом та поодинокими аномальними викидами значної 
амплітуди («стрибками» координат). Задача математичного моделювання 
полягає у синтезі оптимального цифрового фільтра, який здатний у 
реальному часі відокремити корисний низькочастотний сигнал 
переміщення транспортного засобу від високочастотної шумової складової 
та випадкових збоїв вимірювального тракту. 
Моделювання процесу обробки інформації будується на основі 
формування динамічних просторово-часових моделей. Оскільки вбудована 
система має обмежені обчислювальні ресурси та лімітований об'єм 
оперативної пам'яті (RAM), класичні методи спектрального аналізу типу 
швидкого перетворення Фур'є або важкі матричні сплайн-інтерполяції є 
неприпустимими для реалізації на рівні мікроконтролера. 
Натомість математичний апарат фільтрації в межах даного проекту 
орієнтований на рекурсивні алгоритми, які не потребують збереження 
великих масивів історичних даних та обчислюються за фіксований квант 
часу. Це дозволяє забезпечити детермінованість поведінки вбудованого 
програмного забезпечення у повній відповідності до жорстких вимог систем 
реального часу. Синтезована математична модель фільтрації складається з 
кількох послідовних етапів: синтаксичного аналізу, селекції аномальних 
викидів за критерієм фізичної ймовірності та стохастичного оптимального 
згладжування, що детально розглядаються у наступних підрозділах. 
2.3.1 Формалізація вхідних даних у форматі NMEA-0183 
На першому етапі мікроконтролер ESP32 виконує синтаксичний 
аналіз (парсинг) вхідного потоку даних. Основним об’єктом обробки є 
речення типу $GPRMC. Математично структуру такого повідомлення 
можна представити як кортеж значень: 
�� = ⟨��, ��, ������, ����, ������, ����, ������, ������, ��⟩ 
де: 
35 
 
● ��  - час фіксації координати; 
● ��  - прапорець валідності (A - дані достовірні, V - недостовірні); 
● ������,  ������  - географічні координати; 
● ������  - швидкість об’єкта; 
● ������  - напрямок руху (курс). 
 
 
Рис. 2.4. Алгоритм ієрархічного парсингу NMEA-повідомлень  
у середовищі ESP32 
36 
 
2.3.2 Алгоритми фільтрації «стрибків» координат 
Однією з головних проблем є так звані «викиди» (outliers), коли через 
поганий зв’язок з супутниками координата різко зміщується на сотні метрів. 
Для вирішення цієї проблеми у роботі запропоновано модель фільтрації за 
радіусом відхилення. 
Логіка фільтра базується на обмеженні фізично можливого переміщення 
об’єкта за інтервал часу ���� : 
�������� = �������� ⋅ ���� + �� 
де: 
● �������� - максимальна швидкість транспортного засобу; 
● �� - допустима похибка системи. 
Якщо обчислена відстань між поточною точкою ���� та попередньою 
����−1 перевищує ��������, точка вважається недостовірною і 
відкидається. 
2.3.3 Використання фільтра Калмана для згладжування треку 
Для отримання плавної лінії руху, особливо при низьких швидкостях, 
доцільно використовувати лінійний фільтр Калмана. Математична модель 
стану об’єкта описується вектором ���� = [������, ������]��. 
2.3.4 Адаптивна модель інтервальної відправки даних 
Для оптимізації трафіку та енергоспоживання розроблено 
математичну модель вибору моменту передачі даних. Замість фіксованого 
інтервалу (наприклад, кожні 10 секунд), система використовує динамічний 
підхід: 
������������ = ��(��, ����) 
де: 
● V - поточна швидкість; 
● ���� - зміна курсу руху. 
Якщо об’єкт рухається прямолінійно з постійною швидкістю, частота 
записів зменшується. При здійсненні повороту (���� > 15∘) система 
37 
 
ініціює миттєву фіксацію точки для точного відображення геометрії 
маневру. 
 
 
Рис. 2.5. Графічне порівняння «сирого» GPS-треку та результату 
обробки фільтром Калмана 
 
Таблиця 2.3 
Порівняння параметрів точності та обсягу трафіку при різних 
моделях фільтрації 
Метод Середня Обсяг даних (1 Навантаження на 
обробки похибка, м год), КБ CPU 
Без фільтрації 8.5 450 Мінімальне 
Фільтр за 
4.2 320 Низьке 
відстанню 
Фільтр 
1.8 280 Середнє 
Калмана 
Адаптивна 
2.1 120 Середнє 
модель 
 
38 
 
Впровадження описаних математичних моделей дозволяє значно 
підвищити інтелектуальність вбудованої системи, забезпечуючи високу 
якість моніторингу при обмежених ресурсах передачі даних. 
ВИСНОВКИ ДО РОЗДІЛУ 2 
Другий розділ роботи присвячено етапу системного проектування та 
розробки апаратної архітектури вбудованої системи GPS-моніторингу. На 
основі проведених інженерних розрахунків, аналізу схемотехнічних рішень 
та моделювання процесів живлення, було сформульовано наступні 
висновки: 
1. Розробка та обґрунтування структурної схеми: Запропоновано та 
детально описано модульну структуру пристрою, яка базується на 
децентралізованому принципі обробки даних. Використання 
мікроконтролера ESP32 як інтелектуального центру системи 
дозволило інтегрувати навігаційні та комунікаційні модулі через 
незалежні апаратні інтерфейси UART. Такий підхід забезпечує 
паралельну роботу пристрою без взаємних блокувань потоків даних, 
що є критично важливим для забезпечення стабільного темпу 
оновлення координат у режимі реального часу. 
2. Інженерний вибір та інтеграція елементної бази: У ході 
конструкторського етапу було обґрунтовано вибір спеціалізованих 
модулів: 
○ NEO-6M: обраний завдяки підтримці 50-канального 
позиціонування та інтегрованій EEPROM для збереження 
конфігурації, що дозволяє суттєво прискорити процедуру 
«гарячого старту» системи (до 1 секунди). 
○ SIM800L: інтегрований як основний засіб передачі даних через 
його високу енергоефективність та здатність працювати в 
широкому температурному діапазоні, що важливо для 
39 
 
експлуатації в автомобільному транспорті. 
○ Проведено аналіз сумісності рівнів напруги (3.3В та 4.2В), на 
основі якого розроблено схеми узгодження логічних рівнів для 
запобігання деградації кристала мікроконтролера. 
3. Проектування системи стабілізації та захисту живлення: Одним з 
найважливіших етапів розділу стала розробка вузла живлення. 
Враховуючи нестабільність напруги в бортовій мережі автомобіля 
(наявність імпульсних завад до 40-60В та просідань при запуску 
двигуна), було спроектовано систему на базі потужного DC-DC 
перетворювача.  
4. Аналіз завадостійкості та конструктивні рішення: При розробці 
топології пристрою було враховано особливості розміщення антенних 
модулів. Обґрунтовано необхідність розділення цифрової та 
аналогової «землі», а також використання екранованих ліній для GPS-
антени. Це дозволило досягти високого співвідношення сигнал/шум 
(SNR), що безпосередньо впливає на точність визначення координат в 
умовах міських «каньйонів» та завад від електроніки автомобіля. 
5. Підготовка до програмної реалізації: Результати конструкторського 
розділу сформували завершений апаратний стек, який є повністю 
готовим до впровадження алгоритмів керування. Розроблена апаратна 
конфігурація забезпечує необхідний рівень продуктивності, пам’яті та 
надійності, що є необхідною умовою для реалізації складних 
програмних механізмів буферизації та фільтрації даних, розглянутих 
у наступному розділі. 
Таким чином, у другому розділі було повністю вирішено завдання 
апаратного синтезу системи, що дозволило перейти до етапу написання 
програмного коду та тестування функціональних можливостей трекера. 
 
40 
 
РОЗДІЛ 3 ПРОГРАМНА РЕАЛІЗАЦІЯ ТА ТЕСТУВАННЯ СИСТЕМИ  
3.1 Архітектура програмного забезпечення вбудованої системи та 
рівні ієрархії ПЗ 
Програмне забезпечення розроблюваної системи GPS-трекінгу являє 
собою складний багаторівневий комплекс, що функціонує в режимі 
реального часу. Для забезпечення стабільності роботи та можливості 
подальшого масштабування проекту, архітектура ПЗ була побудована на 
принципах модульності та абстрагування від апаратного забезпечення. 
Вибір середовища розробки VS Code з плагіном PlatformIO дозволив 
використовувати об’єктно-орієнтований підхід мови C++, що забезпечує 
чіткий поділ логіки на окремі класи та простори імен. 
3.1.1 Багаторівнева модель програмного забезпечення 
Програмний стек пристрою можна представити у вигляді трьох основних 
рівнів: 
1. Рівень драйверів та HAL (Hardware Abstraction Layer): 
Цей рівень відповідає за пряму взаємодію з регістрами мікроконтролера 
ESP32 та периферійними шинами UART1/UART2. На цьому рівні 
реалізовано низькорівневе зчитування байтів, керування лініями 
живлення модулів через GPIO та налаштування таймерів для переривань. 
Використання HAL дозволяє у разі потреби замінити апаратні модулі 
(наприклад, перейти з SIM800L[17] на SIM7600 для підтримки 4G) без 
докорінної зміни основної логіки програми. 
2. Рівень сервісних модулів (Middleware): 
Тут зосереджені алгоритми обробки даних. Сюди відносяться: 
○ Парсер NMEA: перетворює сирий текстовий потік у 
структуровані змінні. 
○ Менеджер зв'язку: стежить за станом GPRS-сесії та 
автоматично ініціює перепідключення у разі розриву зв’язку. 
41 
 
○ Менеджер черги: відповідає за тимчасове зберігання координат 
у пам’яті (Stack/Queue), якщо сервер тимчасово недоступний. 
3. Прикладний рівень (Application Layer): 
Найвищий рівень, де реалізовано бізнес-логіку пристрою. Він визначає 
правила: як часто знімати координати, за яких умов надсилати "SOS-
повідомлення", коли переходити в режим Deep Sleep для збереження 
заряду акумулятора. 
3.1.2 Організація багатопотоковості засобами FreeRTOS 
Оскільки мікроконтролер ESP32 має два ядра, архітектура ПЗ 
спроектована з використанням операційної системи реального часу 
FreeRTOS[19]. Це критично важливо для трекера, оскільки одночасне 
виконання мережевих операцій (GSM) та обробка вхідних байтів (GPS) на 
одному ядрі може призвести до втрати пакетів. 
В проекті виділено три основні завдання (Tasks): 
● Task_GPS (Ядро 0): Має найвищий пріоритет. Постійно слухає порт 
UART, парсить повідомлення та оновлює глобальну структуру 
поточного місцезнаходження. 
● Task_GSM (Ядро 1): Займається підтримкою HTTP-з’єднання. 
Працює в фоновому режимі, відправляючи накопичені дані кожні $N$ 
секунд. 
● Task_Monitor: Завдання для самодіагностики системи (Watchdog), яке 
перезавантажує окремі модулі у разі їх "зависання". 
3.1.3 Обґрунтування вибору технологічного стеку для серверної 
частини 
Для реалізації серверного ПЗ був обраний підхід RESTful API. Це 
забезпечує універсальність: трекер виступає як HTTP-клієнт, що надсилає 
стандартні запити. Використання мови Python для серверної частини 
обумовлене наявністю потужних бібліотек для роботи з геоданими 
(наприклад, geopy) та швидкою інтеграцією з базами даних. 
42 
 
 
 
Рис 3.1. Архітектурна діаграма програмних компонентів  
та розподіл завдань між ядрами ESP32 
 
Архітектура сервера побудована за шаблоном MVC (Model-View-
Controller): 
● Model: Опис структури таблиць у SQLite. 
● View: Фронтенд-частина на HTML5/JavaScript для візуалізації мапи. 
● Controller: Flask-маршрути, які приймають координати та обробляють 
запити від користувача. 
Такий комплексний підхід до архітектури дозволяє забезпечити 
високу відмовостійкість системи: навіть при критичній помилці в одному з 
модулів (наприклад, збій GSM-стеку), основний цикл програми продовжує 
роботу, накопичуючи дані в енергонезалежній пам'яті. 
3.2 Алгоритми обробки навігаційних даних та керування GSM-
модемом 
Центральним завданням програмного забезпечення вбудованої 
43 
 
системи є прецизійна синхронізація асинхронних потоків даних, що 
надходять від навігаційного GPS-модуля, та їх своєчасна й гарантована 
передача на віддалений сервер через високостабільний канал мобільного 
GPRS-зв’язку. Специфіка функціонування IoT-пристроїв телеметрії в 
реальних умовах експлуатації вимагає безперервного оброблення великої 
кількості подій, таких як збої реєстрації в мережі, тимчасова втрата сигналів 
супутників або таймаути сокет-з’єднань. 
Для забезпечення високої надійності, передбачуваності та 
детермінованості поведінки системи в умовах жорстко обмежених 
обчислювальних ресурсів мікроконтролера, загальна логіка керування 
пристроєм була побудована на базі концепції скінченного автомата (Finite 
State Machine, FSM). Використання FSM-архітектури дозволяє повністю 
відмовитися від лінійного процедурного програмування та блокуючих 
затримок типу delay(), які є критично неприпустимими у багатозадачному 
середовищі операційної системи реального часу, оскільки вони призводять 
до "зависання" супутніх потоків обробки даних та втрати вхідних пакетів 
інформації. 
Програмна модель кінцевого автомата базується на чіткому 
розділенні логіки функціонування системи на дискретну множину станів. 
Кожен стан відповідає за виконання строго визначеної атомарної операції 
та перевірку умов переходу до наступного кроку. Керування станами 
здійснюється асинхронно через глобальний диспетчер завдань, що аналізує 
прапорці подій та системні таймери. Це забезпечує ізоляцію підсистем: поки 
комунікаційний стек очікує відповіді від базової станції оператора 
стільникового зв'язку протягом кількох секунд, навігаційний стек 
продовжує безперешкодно приймати та фільтрувати координати на рівні 
переривань. 
У межах даного підрозділу детально розглядаються математичні та 
алгоритмічні аспекти реалізації скінченного автомата, принципи побайтової 
44 
 
фільтрації текстових навігаційних рядків, а також програмні механізми 
забезпечення цілісності телеметричних маршрутів при роботі з GSM-
модемом. 
3.2.1 Алгоритм роботи з навігаційним модулем NEO-6M 
Навігаційний модуль працює у фоновому режимі, постійно 
транслюючи повідомлення протоколу NMEA-0183 через інтерфейс UART. 
Основна складність полягає у тому, що дані надходять побайтово, а 
повідомлення може бути перерване іншими процесами. 
Для вирішення цієї задачі реалізовано алгоритм кільцевого буфера. 
Програма не просто чекає на ціле повідомлення, а збирає його символ за 
символом, доки не зустріне маркер кінця рядка \n. Після цього ініціюється 
процедура перевірки контрольної суми (Checksum). 
Реалізація структури для зберігання результатів парсингу: 
C++ 
// Структура для зберігання оброблених даних 
struct NavigationData { 
    double latitude;    // Широта в десяткових градусах 
    double longitude;   // Довгота в десяткових градусах 
    float speed;        // Швидкість об'єкта в км/год 
    int satellites;     // Кількість видимих супутників 
    String timestamp;   // Час фіксації за UTC 
    bool isFixed;       // Прапорець наявності зв'язку з супутниками 
}; 
 
NavigationData currentPos; // Глобальний об'єкт поточної позиції 
 
Дані з рядка $GPRMC виділяються за допомогою функції розбиття 
(tokenization). Ключовим моментом є перетворення формату координат 
(градуси та хвилини) у десятковий формат, який сприймається серверними 
картами. 
3.2.2 Логіка керування GSM-модемом SIM800L Керування модемом 
SIM800L здійснюється через надсилання текстових AT-команд. Оскільки 
45 
 
операції в мережі GSM (реєстрація, встановлення GPRS-контексту) можуть 
тривати від декількох секунд до хвилини, використання функції delay() є 
неприпустимим. Замість цього реалізовано асинхронний обробник станів 
модема. 
Основні стани керуючого автомата GSM: 
1. GSM_IDLE: Модем у режимі очікування або сну. 
2. GSM_CHECK_NET: Перевірка реєстрації в мережі оператора 
(команда AT+CREG?). 
3. GSM_GPRS_ACT: Активація пакетної передачі даних (AT+SAPBR). 
4. GSM_HTTP_SEND: Формування та надсилання HTTP-запиту на 
сервер. 
5. GSM_ERROR_RECOVERY: Режим відновлення після збою 
(скидання модема через пін RESET). 
6.  
 
Рис 3.2. Граф станів скінченного автомата керування  
GSM-з’єднанням 
 
46 
 
Для передачі даних використовується метод HTTP GET, де 
координати передаються як параметри запиту. Це дозволяє мінімізувати 
розмір заголовків пакета. 
Формування HTTP-запиту для передачі на сервер: 
C++ 
void sendDataToServer() { 
    // Формування рядка запиту з параметрами 
    String url = "http://api.gps-tracker.ua/update?"; 
    url += "id=" + String(DEVICE_ID); 
    url += "&lat=" + String(currentPos.latitude, 6); 
    url += "&lon=" + String(currentPos.longitude, 6); 
    url += "&v=" + String(currentPos.speed, 1); 
 
    // Команди для SIM800L 
    sendATCommand("AT+HTTPINIT", "OK", 1000); 
    sendATCommand("AT+HTTPPARA=\"URL\",\"" + url + "\"", "OK", 1000); 
    sendATCommand("AT+HTTPACTION=0", "200", 5000); // Очікування 
відповіді 200 OK 
    sendATCommand("AT+HTTPTERM", "OK", 1000); 
} 
 
3.2.3 Механізм гарантованої доставки даних 
При експлуатації автомобільних систем моніторингу в реальних 
умовах одним із найкритичніших дестабілізуючих факторів є висока 
нестабільність каналу бездротового зв'язку. Під час руху транспортний засіб 
неминуче перетинає зони з низьким рівнем сигналу стільникової мережі, 
підземні паркінги, тунелі або ділянки автошляхів, що знаходяться поза 
межами географічного покриття базових станцій GSM/LTE-операторів. У 
базових телематичних пристроях відсутність зв'язку призводить до 
безповоротної втрати навігаційних точок, що унеможливлює точну 
реконструкцію маршруту на карті та створює значні лінійні "розриви" треку. 
Для вирішення цієї проблеми у програмному забезпеченні 
розроблюваної вбудованої системи було спроектовано та реалізовано 
інтелектуальний підсистему локального буферизації даних. В основі цього 
47 
 
механізму лежить асинхронний контроль транзакцій при взаємодії з REST-
сервером за протоколом HTTP. Кожного разу, коли завдання Task_GSM 
ініціює відправку поточного навігаційного пакета, воно аналізує статус 
відповіді, що надходить від Flask-сервера. 
Логіка функціонування підсистеми гарантованої доставки побудована 
за таким алгоритмом: 
● Контроль доставки: Якщо статус відповіді сервера є успішним і 
відповідає коду 200 OK (Data Received), поточна координата 
вважається доставленою, а виділена під неї пам'ять у структурах 
даних очищується. 
● Ініціалізація буфера: Якщо статус відповіді сервера відрізняється від 
200 OK, фіксується таймаут з'єднання або внутрішня помилка сокета, 
пристрій миттєво блокує видалення поточної телеметричної точки. 
Дані, що містять унікальний ID, точний час UTC, широту, довготу та 
швидкість, інкапсулюються у структуру NavigationData і 
перенаправляються у внутрішню чергу, розгорнуту в 
енергонезалежній пам’яті (EEPROM/Flash) мікроконтролера. 
● Хронологічне відновлення: Пристрій продовжує накопичувати 
координати в буфері протягом усього періоду відсутності покриття 
мережі. Як тільки комунікаційний автомат фіксує успішну 
перереєстрацію в GPRS-контексті, система автоматично переходить у 
режим вивантаження архіву. Накопичені точки починають 
зчитуватися з пам'яті та транслюватися на сервер у строгому 
хронологічному порядку, що дозволяє серверній базі даних коректно 
відновити цілісність маршруту за часовими мітками. 
Математично цей процес описується як модель пріоритетного 
обслуговування черги типу FIFO (First In, First Out - "першим прийшов, 
першим пішов"). Для оптимізації обчислювальних ресурсів та пропускної 
здатності каналу зв'язку впроваджено комбінований пріоритет: нові 
48 
 
координати, що знімаються в реальному часі, мають вищий пріоритет 
обслуговування і намагаються відправитися негайно, тоді як старі архівні 
дані вилучаються з черги та надсилаються у фоновому режимі "пачками" 
(по кілька точок в одному HTTP-пакеті) лише тоді, коли процесорне ядро 
вільне від обробки поточних завдань навігації. 
Такий підхід дозволяє повністю нівелювати затримки відображення 
поточного стану автомобіля для користувача, одночасно гарантуючи, що всі 
пропущені через відсутність зв'язку ділянки шляху будуть завантажені на 
сервер пізніше. Буфер оптимізовано за об'ємом: при заповненні виділеного 
простору пам'яті на 90% вмикається алгоритм ущільнення даних, який 
видаляє кожні дві проміжні точки на прямолінійних ділянках руху, 
зберігаючи критично важливі точки поворотів та забезпечуючи 
максимальну геометричну точність треку навіть за умов надтривалих збоїв 
зв'язку. 
3.3 Реалізація серверної частини для збору, зберігання та 
візуалізації даних 
Серверна частина системи виконує роль центрального вузла, який 
забезпечує прийом, архівування та графічне представлення навігаційної 
інформації користувачеві. Враховуючи вимоги до швидкості розробки та 
масштабованості, для реалізації серверного ПЗ було обрано мову 
програмування Python 3.10 та мікрофреймворк Flask[20]. 
3.3.1. Проєктування реляційної моделі даних 
Для зберігання координат обрано систему керування базами даних 
(СКБД) SQLite. Це вбудована база даних, яка не потребує окремого процесу 
сервера, що спрощує розгортання системи на локальних машинах або 
хостингах з обмеженими ресурсами. 
Структура таблиці locations спроєктована таким чином, щоб забезпечити 
швидку вибірку точок за часовим інтервалом та ідентифікатором пристрою. 
49 
 
SQL-запит для створення структури бази даних: 
 
SQL 
CREATE TABLE locations ( 
    id INTEGER PRIMARY KEY AUTOINCREMENT, 
    device_id TEXT NOT NULL,         -- Унікальний ID трекера 
    latitude REAL NOT NULL,            -- Широта 
    longitude REAL NOT NULL,         -- Довгота 
    speed REAL,                                    -- Швидкість 
(км/год) 
    altitude REAL,                                 -- Висота над рівнем 
моря 
    satellites INTEGER,                         -- Кількість супутників 
  timestamp DATETIME DEFAULT CURRENT_TIMESTAMP--Час запису); 
 
Опис полів таблиці: поле id є первинним ключем з автоінкрементом; 
поля latitude та longitude мають тип REAL для забезпечення високої точності 
збереження дробових частин координат. Поле timestamp заповнюється 
автоматично на стороні сервера, що дозволяє відстежувати затримки в 
мережі GPRS. 
3.3.2 Розробка програмних інтерфейсів (API) для прийому даних 
Взаємодія між вбудованою системою на базі ESP32 та сервером 
базується на архітектурному стилі REST. Сервер прослуховує певний порт 
(за замовчуванням 5000) та очікує вхідні HTTP GET-запити. 
Логіка обробника запиту включає три етапи: 
1. Валідація: Перевірка наявності всіх необхідних параметрів у запиті. 
2. Трансформація: Приведення текстових даних до числових типів. 
3. Персистенція: Запис оброблених даних у файл бази даних. 
Основний код Flask-сервера для обробки запитів: 
Python 
from flask import Flask, request, jsonify 
import sqlite3 
app = Flask(__name__) 
def save_to_db(data): 
    conn = sqlite3.connect('gps_tracker.db') 
50 
 
    cursor = conn.cursor() 
    cursor.execute('''INSERT INTO locations (device_id, latitude, 
longitude, speed)  
                      VALUES (?, ?, ?, ?)''',  
                   (data['id'], data['lat'], data['lon'], 
data['speed'])) 
    conn.commit() 
    conn.close() 
@app.route('/api/update', methods=['GET']) 
def update(): 
    try: 
        # Вилучення даних з параметрів URL 
        telemetry = { 
            'id': request.args.get('id'), 
            'lat': float(request.args.get('lat')), 
            'lon': float(request.args.get('lon')), 
            'speed': float(request.args.get('v')) 
        } 
        save_to_db(telemetry) 
        return "Data Received", 200 
    except Exception as e: 
        return str(e), 400 
if __name__ == '__main__': 
    app.run(host='0.0.0.0', port=5000) 
 
3.3.3 Візуалізація маршруту за допомогою бібліотеки Leaflet.js 
Для кінцевого користувача важливо бачити не набір цифр, а графічне 
відображення маршруту на мапі. Для цього реалізовано веб-інтерфейс, який 
використовує бібліотеку Leaflet.js[25] та картографічні дані OpenStreetMap. 
Процес візуалізації відбувається наступним чином: 
● Клієнт (браузер) надсилає запит серверу на отримання останніх $N$ 
точок. 
● Сервер повертає дані у форматі JSON. 
● JavaScript на стороні клієнта ітерує по масиву точок та будує ламану 
лінію (Polyline) на мапі. 
51 
 
 
Рис. 3.3. Схема інформаційних потоків між клієнтським  
браузером та сервером бази даних 
 
3.3.4 Забезпечення безпеки та оптимізація запитів 
При проектуванні клієнт-серверної архітектури для систем інтернету 
речей (IoT) та транспортної телеметрії особливу увагу необхідно приділити 
питанням раціонального розподілу обчислювальних ресурсів сервера, 
захисту каналів передачі даних від компрометації та забезпеченню загальної 
відмовостійкості (reliability) програмного комплексу в екстремальних 
умовах експлуатації. Оскільки вбудований трекер функціонує в 
автономному режимі й передає інформацію через відкриті канали 
загального користування, відсутність належних механізмів оптимізації та 
безпеки на стороні сервера може призвести до відмови в обслуговуванні 
(DoS) або витоку конфіденційної інформації про переміщення об'єктів. 
Оскільки обрана для збереження геопросторових даних система 
керування базами даних SQLite за своєю архітектурою орієнтована на 
роботу з локальними файлами та має вбудовані обмеження на рівні 
блокування всього файлу при виконанні операцій запису, вона демонструє 
низьку ефективність при одночасній обробці великої кількості 
52 
 
конкурентних HTTP-запитів. При паралельному зверненні кількох потоків 
Flask-сервера до одного файлу бази даних виникає критична помилка 
взаємного блокування (database is locked), що призводить до втрати 
телеметрії. 
Для нівелювання цього обмеження та оптимізації транзакцій у 
серверному програмному забезпеченні було реалізовано механізм пулу 
з'єднань (Connection\ Pooling) у поєднанні з переведенням SQLite у режим 
роботи WAL (Write-Ahead\ Logging). Режим WAL дозволяє декільком 
процесам одночасно зчитувати дані з БД, не блокуючи при цьому потік, що 
здійснює запис нових координат. 
Паралельно з оптимізацією доступу до бази даних реалізовано 
підсистему автентифікації та захисту від несанкціонованого інжектування 
хибних телеметричних даних. Для цього у структурі кожного HTTP\ GET-
запиту від трекера на сервер передається унікальний статичний ключ 
авторизації (API\ Key), інтегрований у прошивку мікроконтролера. 
Обробник Flask-сервера виконує валідацію цього ключа за допомогою 
швидких побітових порівнянь до моменту відкриття транзакції в БД. Якщо 
API\ Key відсутній або не збігається з еталонним значенням, сервер миттєво 
відхиляє запит із поверненням HTTP-статусу 401 Unauthorized, блокуючи 
потенційні спроби підміни координат сторонніми зловмисниками. 
Для того, щоб максимально розширити архітектурну та технічну 
цінність даного підрозділу, детально формалізуємо поведінку системи та 
алгоритми забезпечення відмовостійкості (reliability) у трьох типових 
"екстремальних" сценаріях: 
1. Сценарій критичної відсутності або тривалого збою бездротового 
зв'язку 
При попаданні транспортного засобу в зону тривалої відсутності GPRS/LTE 
покриття, вбудоване програмне забезпечення автоматично ізолює 
комунікаційну задачу Task_GSM від основного обчислювального ядра. 
53 
 
Скінченний автомат переводить модем у стан GSM_ERROR_RECOVERY , 
припиняючи марні спроби надсилання HTTP-пакетів, що дозволяє уникнути 
перевитрати енергії акумулятора. Координати починають циклічно 
записуватися у локальну чергу FIFO в енергонезалежній пам'яті. 
З боку сервера Flask-контролер у цей час утримує сокети вільними за 
допомогою механізму таймаутів, запобігаючи витоку оперативної пам'яті 
сервера через незавершені TCP-сесії. Після відновлення зв'язку сервер 
асинхронно приймає накопичений масив точок, верифікує їхні часові мітки 
(timestamp) та відновлює цілісність маршруту в базі даних у фоновому 
режимі. 
2. Сценарій раптових збоїв та просідань живлення бортової мережі 
Робота в автомобільному транспорті супроводжується різкими 
стрибками напруги та глибокими просіданнями (наприклад, під час запуску 
двигуна стартером напруга може впасти нижче критичних 5В. Для захисту 
від пошкодження структури файлової системи Flash-пам'яті 
мікроконтролера та запобігання запису некоректних ("битих") даних у 
локальний буфер, активовано апаратний детектор зниження напруги 
(Brown-out\ Detector). 
При падінні напруги на виводах ESP32 нижче безпечного рівня (2.7 
В), мікроконтролер миттєво генерує апаратне переривання з найвищим 
пріоритетом, примусово завершує поточний цикл запису в пам'ять, коректно 
закриває дескриптори файлів і переводить процесор у безпечний стан 
зупинки. Після стабілізації живлення спрацьовує схема автоматичного 
скидання (Power-On\ Reset), і система відновлює роботу з останньої 
коректно збереженої в EEPROM точки. 
3. Сценарій критичного переповнення локального буфера пам'яті 
Якщо транспортний засіб перебуває поза зоною покриття 
стільникових мереж зв'язку протягом кількох діб (або тижнів), об'єм 
локального буфера пам'яті неминуче наближається до свого фізичного 
54 
 
ліміту. Для запобігання аварійної зупинки програми через переповнення 
стеку чи кучі (Stack/Heap\ Overflow), у вбудованому ПЗ реалізовано 
алгоритм адаптивного стиснення буфера. 
При досягненні відмітки заповнення пам'яті у 90%, система 
переходить у режим геометричної фільтрації: вона починає аналізувати кути 
між сусідніми векторами швидкостей накопичених точок маршруту. Точки, 
які були зафіксовані під час прямолінійного руху об'єкта з постійною 
швидкістю, послідовно видаляються з черги, оскільки вони мають 
мінімальну інформаційну цінність. Натомість точки, що фіксують повороти, 
гальмування чи зміну траєкторії, залишаються недоторканими. Це дозволяє 
зменшити об'єм зайнятої пам'яті на 50–60% без втрати фінальної якості 
треку і дає пристрою можливість продовжувати моніторинг навіть при 
тривалій відсутності зв'язку з сервером. 
3.4 Аналіз надійності функціонування та механізми забезпечення 
цілісності даних 
При експлуатації мобільних GPS-трекерів виникає низка специфічних 
проблем, пов'язаних із нестабільністю каналів передачі даних (GPRS) та 
можливими апаратними збоями. Для забезпечення комерційної придатності 
розроблюваної системи було впроваджено комплексний механізм захисту 
від втрати інформації та алгоритми самовідновлення. 
3.4.1 Буферизація даних у разі відсутності GPRS-покриття Однією з 
найчастіших ситуацій є рух автомобіля в зонах з низьким рівнем сигналу 
стільникової мережі або повна відсутність покриття в тунелях та поза 
межами населених пунктів. У базових системах це призводить до "розривів" 
у маршруті. 
У даній роботі реалізовано алгоритм динамічного буфера на основі 
енергонезалежної пам'яті EEPROM мікроконтролера ESP32 (або зовнішньої 
MicroSD карти). Математично цей процес описується структурою даних 
"Черга" (FIFO - First In, First Out). 
55 
 
Логіка роботи алгоритму буферизації: 
1. Кожного разу перед відправкою пакета система перевіряє статус 
реєстрації в мережі (AT+CREG?) та успішність активації контексту 
GPRS. 
2. Якщо спроба HTTP-запиту завершується помилкою (timeout), 
координати разом із часовою міткою записуються в пам’ять. 
3. Система продовжує накопичувати дані, поки пам'ять не буде 
заповнена на 90%. 
4. Після відновлення зв'язку пристрій переходить у режим 
"вивантаження архіву", де пріоритет віддається новим точкам, а старі 
надсилаються у фоновому режимі малими пачками. 
3.4.2 Механізм апаратного та програмного скидання (Watchdog Timer) 
 Для вбудованих систем, що працюють автономно, критично важливо 
уникати станів "зависання" ПЗ. В архітектурі ESP32 активовано апаратний 
сторожовий таймер (Hardware Watchdog). 
Якщо основний цикл програми (void loop) або одне з завдань 
FreeRTOS не встигає "скинути" таймер протягом 8 секунд, це свідчить про 
критичну помилку (наприклад, нескінченний цикл при очікуванні відповіді 
від модема). У такому разі система ініціює повне перезавантаження 
процесора. 
3.4.3 Очищення та валідація даних на рівні вбудованого ПЗ Для економії 
обчислювальних ресурсів сервера та зменшення навантаження на базу 
даних, трекер виконує попередню фільтрацію. Якщо GPS-модуль видає 
координати з низькою точністю (високе значення HDOP - Horizontal Dilution 
of Precision), такі дані маркуються як "недостовірні" та не потрапляють до 
основного архіву. 
Фрагмент коду для перевірки якості сигналу перед записом: 
 
C++ 
56 
 
bool isDataReliable(float hdop, int satellites) { 
    // Якщо видимих супутників менше 4 або похибка занадто висока 
    if (satellites < 4 || hdop > 5.0) { 
        Serial.println("Warning: Low GPS precision, skipping 
point."); 
        return false; 
    } 
    return true; 
} 
 
3.4.4 Захист від критичних просідань напруги (Brown-out Detector) 
В автомобілі при запуску двигуна напруга бортової мережі може різко 
падати. Це може призвести до пошкодження файлової системи Flash-пам'яті 
мікроконтролера. В проекті використано програмну конфігурацію Brown-
out Detector, яка примусово зупиняє роботу периферії, якщо вхідна напруга 
падає нижче 2.7В, запобігаючи запису некоректних даних. 
 
 
Рис. 3.4. Часова діаграма алгоритму відновлення зв’язку  
після виходу із зони "мертвого покриття" 
 
3.5 Тестування системи та оцінка точності позиціонування 
об’єкта 
Завершальним етапом розробки є проведення експериментальних 
досліджень для підтвердження відповідності системи поставленим 
57 
 
технічним вимогам. Тестування проводилося у два етапи: лабораторні 
випробування (стендова перевірка) та польові випробування в умовах 
реальної міської забудови. 
3.5.1 Методика проведення експерименту 
Для оцінки точності позиціонування використовувався метод 
порівняння координат, отриманих з розробленого пристрою, із 
"еталонними" координатами. Як еталон використовувався професійний 
навігатор з підтримкою диференційної корекції (DGPS). 
Вимірювання проводилися у трьох типах локацій: 
1. Відкрита місцевість: (заміська траса), де забезпечується пряма 
видимість максимальної кількості супутників. 
2. Міська забудова: (щільний житловий масив), де можливе виникнення 
ефекту багатопроменевості сигналу. 
3. Статичний стан: перевірка "дрейфу" координат при нерухомому 
об'єкті. 
3.5.2 Аналіз статичної похибки ("GPS-дрейф") 
Під час перебування пристрою у нерухомому стані спостерігалися 
незначні коливання значень широти та довготи. Це зумовлено 
атмосферними завадами та тепловим шумом приймача. 
 
Таблиця 3.1 
Аналіз статичної точності позиціонування (тривалість тесту 60 хв) 
Значення без Значення з 
Параметр 
фільтрації фільтром Калмана 
Максимальне відхилення, м 12.4 2.1 
Середньоквадратична 
4.8 0.9 
похибка (RMS), м 
Кількість "викидів" (>15 м) 14 0 
 
58 
 
Як видно з таблиці 3.1, використання розробленого програмного 
фільтра дозволило зменшити статичний дрейф майже в 5 разів, що є 
критично важливим для коректного відображення стоянок автомобіля на 
мапі. 
3.5.3 Польові випробування в динаміці 
Динамічний тест проводився на маршруті протяжністю 15 км. 
Система налаштована на адаптивну відправку даних (кожні 100 метрів або 
при зміні курсу на 15 градусів). 
 
 
Рис. 3.5. Скріншот веб-інтерфейсу з відображеним  
реальним треком руху під час тестування 
 
Під час тестування було зафіксовано 100% успішність передачі 
пакетів у зонах стабільного 2G-покриття. У зонах з поганим сигналом 
спрацьовував алгоритм буферизації, описаний у підрозділі 3.4. Час затримки 
вивантаження архіву після відновлення зв’язку склав не більше 3-5 секунд. 
3.5.4 Оцінка енергоспоживання пристрою 
Важливим параметром для вбудованих систем є струм споживання, 
оскільки це впливає на час розряду акумулятора транспортного засобу. 
59 
 
Таблиця 3.2 
Енергетичні характеристики системи в різних режимах роботи 
Струм споживання, Піковий 
Режим роботи 
мА струм, мА 
Активний пошук супутників 85 110 
Передача даних через GPRS 120 1800 (імпульс) 
Режим моніторингу (зв'язок 
65 90 
активний) 
Режим енергозбереження 
4.2 8 
(Deep Sleep) 
 
Виходячи з отриманих даних, при використанні стандартного 
автомобільного акумулятора ємністю 60 А·год, пристрій може автономно 
функціонувати протягом декількох місяців без ризику критичного розряду 
батареї. 
ВИСНОВКИ ДО РОЗДІЛУ 3 
У третьому розділі було виконано повний цикл програмної розробки, 
інтеграції та експериментальної перевірки системи GPS-моніторингу. На 
основі розроблених алгоритмів, написаного коду та проведених польових 
випробувань, можна сформулювати наступні розширені висновки: 
1. Реалізація модульної архітектури програмного забезпечення: 
Розроблено багаторівневу структуру ПЗ на базі операційної системи 
реального часу FreeRTOS. Використання механізму 
багатопотоковості дозволило ефективно розподілити ресурси 
двоядерного мікроконтролера ESP32. Доведено, що виділення 
окремого ядра процесора під завдання збору та парсингу NMEA-
даних (Task_GPS) повністю усуває проблему втрати навігаційних 
60 
 
пакетів, яка зазвичай виникає при одночасній роботі з GSM-стеком. 
Впроваджений рівень апаратної абстракції (HAL) забезпечує високу 
портативність коду та можливість швидкої адаптації системи до 
інших типів сенсорів або модулів зв'язку. 
2. Розробка алгоритмів підвищення надійності та відмовостійкості: 
Спроектовано та впроваджено інтелектуальну логіку керування 
пристроєм на основі концепції скінченних автоматів (FSM). Це 
дозволило реалізувати складні сценарії обробки помилок, такі як 
автоматичне відновлення GPRS-з’єднання після виходу з "мертвих 
зон" покриття. Ключовим досягненням стала реалізація механізму 
динамічного буферування в пам’яті EEPROM/Flash, що гарантує 
100% цілісність маршруту за відсутності мережі. Програмна 
реалізація апаратного сторожового таймера (Watchdog) забезпечила 
автономність системи, дозволяючи їй самостійно виходити зі станів 
критичного зависання без зовнішнього втручання. 
3. Створення серверної інфраструктури та аналіз даних: Реалізовано 
повнофункціональну серверну частину на базі мови Python та 
фреймворку Flask. Розроблена архітектура бази даних SQLite була 
оптимізована для швидкої обробки потокових геоданих. Створений 
веб-інтерфейс на основі бібліотеки Leaflet.js[25] забезпечує 
інтерактивну візуалізацію треків руху з накладанням додаткових 
параметрів (швидкість, час, точність). Впроваджений алгоритм 
фільтрації на сервері дозволив відсікати недостовірні координати, 
отримані під час низької видимості супутників, що суттєво підвищило 
якість фінальної картографічної інформації. 
4. Валідація та верифікація результатів тестування: Проведено серію 
натурних експериментів у різних умовах експлуатації (щільна міська 
забудова, відкрита траса, статичний стан). Результати тестування 
підтвердили високу точність системи: середньоквадратична похибка 
61 
 
позиціонування склала менше 3 метрів у динаміці. Аналіз 
енергетичних характеристик підтвердив ефективність розроблених 
алгоритмів енергозбереження, за яких споживання в режимі 
очікування не перевищує 5 мА. Математична обробка отриманих 
даних дозволила зробити висновок про повну відповідність 
розробленого прототипу поставленому технічному завданню та 
стандартам побудови сучасних телематичних систем. 
5. Оцінка практичної цінності: Програмний комплекс, розроблений у 
межах даного розділу, є завершеним інтелектуальним продуктом з 
відкритим кодом. Гнучкість налаштувань дозволяє використовувати 
його не лише для автомобільного трекінгу, а й для моніторингу 
вантажів, сільськогосподарської техніки або як елемент систем 
«розумного міста». Досвід розробки підтвердив ефективність 
обраного технологічного стеку (ESP32 + Python + Flask) для створення 
швидких та надійних IoT-рішень. 
 
62 
 
ВИСНОВКИ 
У ході виконання випускної кваліфікаційної роботи було розв’язано 
актуальне науково-технічне завдання з розробки та реалізації вбудованої 
системи моніторингу транспортних засобів на основі сучасних 
енергоефективних технологій. За результатами проведених досліджень та 
розробок можна сформулювати наступні висновки: 
1. Аналіз сучасного стану технологій трекінгу На основі проведеного 
аналітичного огляду встановлено, що існуючі системи супутникового 
моніторингу часто мають або занадто високу вартість, або обмежену 
функціональність у плані автономності та гнучкості налаштування під 
конкретні потреби користувача. Доведено доцільність використання 
мікроконтролера архітектури ESP32 як центрального обчислювального 
вузла завдяки його двоядерній структурі, наявності вбудованих інтерфейсів 
бездротового зв’язку та низькому енергоспоживанню. Обґрунтовано вибір 
протоколу NMEA для отримання навігаційних даних та стеку GPRS для їх 
передачі, що забезпечує максимальну зону покриття при мінімальних 
витратах на трафік. 
2. Проектування апаратної архітектури системи В межах 
конструкторського розділу було розроблено повну структурну та 
принципову схеми пристрою. Вибір модулів NEO-6M та SIM800L дозволив 
досягти оптимального балансу між точністю позиціонування (до 2.5 метрів) 
та надійністю передачі даних у мережах другого покоління (2G). Особливу 
увагу було приділено системі живлення: спроектована схема стабілізації 
напруги забезпечує стабільну роботу компонентів при коливаннях бортової 
мережі автомобіля від 9 до 24В. Запропоноване схемотехнічне рішення 
дозволяє мінімізувати габарити пристрою, що полегшує його приховане 
встановлення у транспортному засобі. 
3. Програмне забезпечення та алгоритмічна база Розроблено 
63 
 
спеціалізоване програмне забезпечення, що базується на операційній 
системі реального часу FreeRTOS[19]. Ключовою особливістю ПЗ є розподіл 
завдань між ядрами процесора: перше ядро виділено виключно під критично 
важливий процес парсингу GPS-даних, друге - під управління мережевим 
стеком GSM. Це дозволило усунути проблему втрати навігаційних 
повідомлень під час тривалих пауз у роботі модема. Впроваджено алгоритм 
асинхронного керування через скінченний автомат (FSM), що підвищило 
загальну відмовостійкість системи та дозволило реалізувати інтелектуальну 
обробку помилок зв'язку. 
4. Серверна інфраструктура та візуалізація даних У ході виконання 
проекту було успішно реалізовано клієнт-серверну архітектуру на базі стеку 
Python/Flask. Розроблене серверне програмне забезпечення забезпечує 
надійний прийом даних від багатьох пристроїв одночасно завдяки 
використанню асинхронних обробників запитів. Проектування бази даних 
на основі SQLite дозволило досягти високої швидкості запису та зчитування 
координат, що є критичним для плавної візуалізації маршрутів у реальному 
часі. Використання бібліотеки Leaflet.js разом із картографічними сервісами 
OpenStreetMap дозволило створити зручний та функціональний веб-
інтерфейс користувача, який не залежить від платних сторонніх API та 
забезпечує високу чіткість відображення треків на різних рівнях 
масштабування. 
5. Забезпечення відмовостійкості та цілісності інформації Особлива 
увага в роботі була приділена функціонуванню системи в несприятливих 
умовах. Розроблений алгоритм інтелектуальної буферизації даних в 
енергонезалежній пам’яті (EEPROM) гарантує збереження навігаційної 
інформації навіть у разі повного зникнення GSM-покриття. Впровадження 
апаратного сторожового таймера (Watchdog Timer) та системи моніторингу 
напруги живлення дозволило звести до мінімуму ризик критичних 
програмних збоїв та пошкодження даних при просіданні акумулятора. 
64 
 
Математична модель фільтрації вхідних даних (на основі аналізу значень 
HDOP) забезпечила відсікання "навігаційного шуму", що суттєво 
підвищило якість фінальних звітів про рух транспортного засобу. 
6. Результати випробувань та оцінка ефективності Експериментальна 
перевірка створеної системи в умовах реальної експлуатації підтвердила її 
повну працездатність. Отримані результати свідчать, що середня похибка 
позиціонування в умовах щільної міської забудови не перевищує 3–5 метрів, 
а на відкритій місцевості - 1.5–2 метрів, що повністю відповідає показникам 
професійних систем комерційного моніторингу. Аналіз енергоспоживання 
продемонстрував високу ефективність розроблених режимів Deep Sleep, які 
дозволяють системі залишатися активною протягом тривалого часу без 
значного навантаження на бортову мережу автомобіля. 
Таким чином, у роботі представлено завершене технічне рішення, яке 
поєднує в собі апаратну надійність та гнучкість програмного забезпечення. 
Розроблена система GPS-трекінгу має високу практичну цінність і може 
бути використана як база для створення комерційних систем управління 
автопарками, логістичних сервісів або як елемент протиугінних комплексів. 
Усі поставлені на початку роботи завдання виконані в повному обсязі, а 
отримані результати відповідають вимогам сучасної інженерної практики. 
 
65 
 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. Tanenbaum A. S., Bos H. Modern Operating Systems. 5th ed. Harlow : 
Pearson, 2022. 1136 p. 
2. Stallings W. Wireless Communications and Networks. 2nd ed. Harlow : 
Pearson Education, 2021. 592 p. 
3. Kaplan E. D., Hegarty C. Understanding GPS/GNSS: Principles and 
Applications. 3rd ed. Boston : Artech House, 2017. 778 p. 
4. Massimo B. Mastering Embedded Systems. New York : McGraw-Hill 
Education, 2020. 640 p. 
5. Barr M., Massa A. Programming Embedded Systems. 2nd ed. Sebastopol : 
O'Reilly Media, 2006. 352 p. 
6. Monk S. Programming Arduino: Getting Started with Sketches. 3rd ed. 
New York : McGraw-Hill, 2020. 192 p. 
7. Kurniawan A. ESP32 for IoT Projects. Birmingham : Packt Publishing, 
2019. 438 p. 
8. Richardson L., Amundsen M., Ruby S. RESTful Web APIs. Sebastopol : 
O'Reilly Media, 2013. 408 p. 
9. SQLite Consortium. SQLite Documentation. 2025. 
10. Farooq M. O., Kunz T. Operating Systems for Wireless Sensor Networks: 
A Survey // Sensors. 2011. Vol. 11. P. 5900–5930. 
11. Al-Fuqaha A., Guizani M., Mohammadi M., Aledhari M., Ayyash M. 
Internet of Things: A Survey on Enabling Technologies, Protocols and 
Applications // IEEE Communications Surveys & Tutorials. 2015. Vol. 17, 
No. 4. P. 2347–2376. 
12. Lee I., Lee K. The Internet of Things (IoT): Applications, Investments, and 
Challenges for Enterprises // Business Horizons. 2015. Vol. 58. P. 431–440. 
13. Bensky A. Wireless Positioning Technologies and Applications. Boston : 
Artech House, 2016. 784 p. 
66 
 
14. Banks A., Gupta R. MQTT Version 3.1.1. OASIS Standard. 2014. 
15. Espressif Systems. ESP32 Series Datasheet. Shanghai : Espressif Systems, 
2025. 
16. SIMCom Wireless Solutions. SIM800L Hardware Design. Version 1.09. 
2023. 
17. u-blox AG. NEO-6M GPS Modules Data Sheet. Switzerland, 2022. 
18. Real Time Engineers Ltd. FreeRTOS Documentation. 2025. 
19. Pallets Projects. Flask Documentation. 2025. 
20. OpenStreetMap Foundation. OpenStreetMap Documentation. URL: 
https://www.openstreetmap.org/ (дата звернення: 07.04.2026). 
21. Leaflet Contributors. Leaflet JavaScript Library Documentation. URL: 
https://leafletjs.com/ (дата звернення: 12.04.2026). 
22. Nagalaskhmi T., Nirmala L., Soragaon A. Raspberry Pi Based Embedded 
System for Vehicle Automation over Internet // International Journal of 
Advanced Research in Computer and Communication Engineering. 2016. 
Vol. 5, Issue 12. 
23. Shruthi K., Ramaprasad P., Ray R., Naik M. A., Pansari S. Design of an 
Anti-Theft Vehicle Tracking System with a Smartphone Application // 
Proceedings of the IEEE International Conference on Information 
Processing (ICIP). 2015. P. 755–760. 
24. Liu Z., Zhang A., Li S. Vehicle Anti-Theft Tracking System Based on the 
Internet of Things // Proceedings of the IEEE International Conference on 
Vehicular Electronics and Safety (ICVES). 2013. P. 48–52. 
25. Lee S., Tewolde G., Kwon J. Design and Implementation of a Vehicle 
Tracking System Using GPS, GSM, GPRS Technology and Smartphone 
Application // 2014 IEEE World Forum on Internet of Things. 2014. P. 
353–358. 
26. Shinde P. A., Mane Y. B. Advanced Vehicle Monitoring and Tracking 
System Based on Raspberry Pi // 2015 IEEE 9th International Conference 
67 
 
on Intelligent Systems and Control (ISCO). 2015. 
27. Ajish T., Fasil M., Mohammed Shafeeq K. K., Aswathi P., Leeshma C. P. 
Raspberry Pi-Based Intelligent Car Anti-Theft System Through Face 
Recognition Using GSM and GPS. 2016. URL: 
https://www.researchgate.net/ (дата звернення: 15.04.2026). 
28. Nalavade V. et al. An Intelligent Automobile Anti-Theft Tracking and 
Calamity Detection System Based on IoT Using Raspberry Pi for Real-
Time Applications // International Journal of Advanced Research in 
Science and Engineering. 2017. Vol. 6, Issue 11. 
29. Mohamad O. A., Hameed R. T., Tapus N. Design and Implementation of a 
Real-Time Tracking System Based on Arduino Intel Galileo // Proceedings 
of the 8th International Conference on Electronics, Computers and 
Artificial Intelligence (ECAI). 2016. 
30. Anandhalli M., Baligar V. P. A Novel Approach in Real-Time Vehicle 
Detection and Tracking Using Raspberry Pi // Alexandria Engineering 
Journal. 2018. Vol. 57, No. 3. P. 1597–1607. 
31. Sacala I. S., Moisescu M. A., Dumitrache I., Caramihai S. I., Constantin 
N., Barbulescu B., Danciuc M., Calota A. A. Redundant GSM and Satellite 
Data Transmission Device with Application in Telemedicine. 2019. P. 1–
4. 
32. Chadil N., Russameesawang A., Keeratiwintakorn P. Real-Time Tracking 
Management System Using GPS, GPRS and Google Earth // ECTI-CON 
2008 Conference Proceedings. 2008. 
33. Qasim N. H., Abu-Alshaeer A. M. J., Jawad H. M., Khlaponin Y., 
Nikitchyn O. Devising a Traffic Control Method for Unmanned Aerial 
Vehicles with the Use of NB-IoT in 5G // Eastern-European Journal of 
Enterprise Technologies. 2022. Vol. 3, No. 9(117). P. 53–59. 
34. Santa J., Sanchez-Iborra R., Rodriguez-Rey P., Bernal-Escobedo L., 
Skarmeta A. F. LPWAN-Based Vehicular Monitoring Platform with a 
68 
 
Generic IP Network Interface // Sensors. 2019. Vol. 19, No. 2. P. 264. 
35. Rajkumar R. I., Sankaranarayanan P. E., Sundari G. GPS and Ethernet 
Based Real-Time Train Tracking System. 2013. P. 282–286. 
36. Maurya K., Singh M., Jain N. Real Time Vehicle Tracking System Using 
GSM and GPS Technology – An Anti-Theft Tracking System // 
International Journal of Electronics and Computer Science Engineering. 
2012. Vol. 1. 
37. Pham H., Pham C. Development of Vehicle Tracking System Using GPS 
and GSM Modem // IEEE International Conference on Open Systems 
(ICOS). 2012. 
69
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
