Як GPS-моніторинг допомагає під час повітряних тривог: захист від глушіння сигналу

Оголошують тривогу. Через десять хвилин диспетчер відкриває карту й бачить, що половина парку зникла, а одна фура стоїть посеред поля за 200 кілометрів від маршруту. Водій на зв'язку, каже — усе гаразд, їдемо за графіком.

Найперша думка власника: «Полетіло обладнання». Насправді обладнання ціле й працює як має. Проблема не в трекері, а в небі над ним.

Що насправді відбувається з сигналом

GPS-трекер нічого не передає на супутник — він тільки слухає. Сигнал, який до нього доходить, слабший за фоновий шум, і саме тому його так легко зіпсувати. Під час роботи засобів радіоелектронної боротьби це відбувається за двома сценаріями.

Глушіння (jamming). Ефір забивається потужним шумом на частотах GPS. Приймач просто не бачить супутників і не може обчислити позицію. Трекер живий, GSM-зв'язок є, він продовжує виходити на сервер — але координат у повідомленнях немає або вони «заморожені» на останній відомій точці.

Підміна (spoofing). Складніший і неприємніший випадок. Приймач отримує фальшивий сигнал, який виглядає правдоподібнішим за справжній, і чесно рахує за ним позицію. Координати є, вони валідні з погляду приймача — і повністю неправдиві.

У системі моніторингу це видно за характерними ознаками:

• об'єкт «переїжджає» за тисячі кілометрів — у сусідню країну, в район аеропорту або взагалі на інший континент, а потім так само стрибком повертається;
• трек рветься на шматки, між точками з'являються прямі лінії через міста й водойми;
• швидкість нульова, а пробіг у звіті росте;
• машина стоїть на місці, але точка «тремтить» у радіусі кількох сотень метрів;
• кілька різних об'єктів опиняються в одній точці одночасно.

Важливо розуміти: жодна з цих ознак не свідчить про несправність трекера. Це нормальна реакція справного приймача на ненормальні умови.

Чому це проблема бізнесу, а не просто «крапка не там»

Якби наслідком була тільки некрасива карта, з цим можна було б жити. Але координати — це основа, на якій рахується все інше.

Пробіг. Один стрибок на 500 кілометрів дописується в пробіг за добу. Далі цей пробіг іде в норми витрати на 100 км, у розрахунок амортизації, у міжсервісні інтервали, в оплату водію, якщо вона прив'язана до кілометражу.

Геозони. Фальшива точка входить у зону — спрацьовує сповіщення про прибуття на об'єкт, якого не було. Або навпаки: машина реально стоїть на розвантаженні, а система цього не бачить, бо для неї вона в іншій області.

Підтвердження перед замовником. Клієнт просить трек за конкретний рейс. Ви відкриваєте звіт і бачите розриви та стрибки. Пояснювати замовнику природу РЕБ у момент суперечки про оплату — не найкраща позиція.

Накопичення помилки. Одна збійна доба непомітна. Тридцять таких діб у місячному звіті дають похибку, після якої цифрами вже не можна користуватися для управлінських рішень.

Як влаштований захист

Захистити приймач від глушіння неможливо — фізику не обійти. Але можна зробити так, щоб система пройшла крізь глушіння з мінімальними втратами й сама відновилася. Це те, що ми налаштовуємо на кожному об'єкті.

Автоматичне перезавантаження трекера

Після тривалого глушіння приймач часто не повертається до нормальної роботи самостійно, навіть коли небо вже чисте. Він залишається в стані, коли супутники нібито є, але фіксу немає — і може висіти так годинами.

Система відстежує сам факт втрати координат і автоматично надсилає команду на перезавантаження. Без виїзду техніка, без дзвінка водієві, без участі диспетчера. Щойно завади зникають, об'єкт повертається в мережу самостійно — зазвичай протягом кількох хвилин, а не наступного ранку, коли хтось помітить проблему вручну.

Окремо відпрацьовується сценарій підміни: якщо об'єкт опиняється там, де його фізично бути не може, це теж триґер для примусового перезапуску.

Буферизація даних

Коли зв'язку немає, трекер не викидає дані — він накопичує їх у внутрішній пам'яті. Після відновлення зв'язку вся ця історія догружається на сервер і стає на своє місце в треку. Правильно налаштований буфер — це різниця між «за вчора даних немає» і «дані прийшли з затримкою на дві години».

Фільтрація на сервері

Це найважливіший і найменш помітний рівень. Кожне повідомлення від трекера проходить перевірку на достовірність, перш ніж потрапити в трек і в звіти:

• фільтр стрибків — система рахує відстань і час між сусідніми точками. Якщо виходить швидкість, неможлива фізично (сідельний тягач «проїхав» 400 км за 30 секунд), точка відкидається;
• фільтр за кількістю супутників — позиція, обчислена за трьома супутниками, недостовірна за визначенням;
• фільтр за HDOP — показник геометрії сузір'я. Висока HDOP означає, що супутники видно, але їх взаємне розташування дає велику похибку;
• обмеження максимальної швидкості — усе, що виходить за реальні можливості техніки, не враховується.

Без цих фільтрів один епізод підміни дописує в місячний звіт зайву тисячу кілометрів. З ними фальшива точка просто не потрапляє в розрахунок.

Що залишається в історії — і чого від неї не варто чекати

Збійні точки прибираються двома шляхами. Більшість відсікається фільтрами автоматично, ще на вході — вони не потрапляють ні в трек, ні в розрахунок пробігу. Те, що все ж осіло в історії, чиститься вручну: повідомлення з некоректними координатами видаляються з бази об'єкта, і звіти за минулий період перераховуються вже без них.

Чого зробити не можна — це домалювати трек там, де його не було. Якщо приймач півгодини не бачив супутників, цих півгодини в історії не з'явиться. На карті ділянка виглядатиме як пряма лінія — «простріл» між останньою достовірною точкою до глушіння і першою після нього. Це не помилка системи й не залишки сміття: це чесне позначення відрізка, де координат просто не існує.

Практичний висновок звідси один. Пробіг по таких ділянках не можна брати з треку — його треба брати звідти, де він виміряний незалежно від супутників.

Приклад вище — реальний об'єкт, автобетонозмішувач, одна доба. До очищення система нарахувала 57.98 км пробігу й максимальну швидкість 205 км/год — для машини, яка фізично не здатна так їхати. Після вилучення недостовірних точок залишилося 16.41 км і 66 км/год. Різниця в 41.57 км — це «пробіг», якого не було, і який без фільтрації пішов би в усі звіти й норми.

Дані, які не залежать від супутників

Найнадійніший спосіб пережити глушіння — мати показники, яким небо взагалі не потрібне. Такі показники в парку є.

Одометр з CAN-шини. Пробіг, який рахує сама машина за обертами коліс. Не залежить від супутників, не стрибає, не має розривів.

Датчик рівня палива в баку. Показує фактичну кількість палива — скільки залилося, скільки зникло, коли й де.

Тут є важливий нюанс, який часто плутають. Витрата палива по CAN — це не виміряна величина, а розрахована. Блок керування двигуна рахує її за часом відкриття форсунок і паспортною продуктивністю розпилювачів, з поправками за тиском у рампі та витратою повітря. Значення живе, воно адаптується під фактичний стан двигуна — але залишається моделлю. ДУТ у баку моделі не будує: він показує, скільки палива фізично зникло з бака.

Тому робочий звіт виглядає так: витрата за ДУТ ÷ пробіг за одометром. Обидві величини — виміряні, жодна з них не залежить від супутників. Навіть якщо машина добу простояла під глушінням і трек порізаний, паливний звіт за місяць залишається коректним.

Наскільки це відчутно на практиці — видно на прикладі вище. Один довгомір, одна доба: по CAN-шині 33.95 л/100 км, по ДУТ — 40.00. Розбіжність 6.05 л/100 км, або майже 4 літри за добу на одній машині. На парку з двадцяти одиниць за місяць це вже цифра, за яку є сенс поборотися.

Це і є практична відповідь на питання «а що робити, коли GPS не працює». Правильно зібрана система не тримається на одному джерелі даних.

Чек-лист: перевірте свій парк

Якщо ви вже користуєтеся моніторингом, ці пункти можна перевірити самостійно або запитати у свого підрядника:

1. Чи налаштовані фільтри достовірності — за швидкістю, кількістю супутників, HDOP. Якщо ні, у ваших звітах уже є сміття.
2. Чи повертаються об'єкти в мережу самі після зникнення сигналу, чи хтось помічає це вручну через день-два.
3. Чи заведений ДУТ хоча б на частину парку — і чи є звіт «витрата за ДУТ на 100 км».
4. Чи знімається одометр з CAN, чи пробіг рахується виключно за GPS-треком.
5. Чи налаштована буферизація — приходять дані за період без зв'язку чи зникають назавжди.
6. Чи чистилася історія за останні місяці, чи в річному звіті лежать усі стрибки як є.

Якщо на більшість пунктів відповідь «не знаю» — це нормально. Це саме те, що має знати підрядник, а не власник парку.

Підсумок

Повітряні тривоги й робота РЕБ стали фоновою умовою, в якій працює український транспорт. Змінити цю умову ми не можемо — але можемо зробити так, щоб вона не з'їдала якість даних, за якими ви приймаєте рішення.

Правильно налаштована система переживає глушіння без втручання людини: трекери відновлюються самі, сміття не потрапляє у звіти, а паливо й пробіг рахуються за джерелами, яким супутники не потрібні.