Моніторинг неслухняних літаків

Автор: Дмитро Однокоз

У цій статті я хочу розказати про побудовану нами систему моніторингу перельотів літаків, які не дуже “хочуть”, щоб їх моніторили. Наша система побудована на публічному функціоналі, який надає відомий міжнародний сервіс Flightradar24 (юрособа зареєстрована в Швеції, як мінімум IT архітектор в Болгарії). Документація по API проста і зрозуміла, тому можна швидко зорієнтуватися в запропонованих можливостях: там 3 справочні запити і 1 про реалтайм польоти з великими можливостями по фільтру. Але результат лиш на перший погляд здається легко досяжним. Про це буде далі. А спершу трохи бази на пальцях, яка повно описана англійською тут (літературно) або тут (технічно). Не претендую на експертність, лише ділюся загальним уявленням, яке маю.

База

В другій половині 19 століття було винайдено електромагнітну теорію, а під кінець 19 століття доведено існування електромагнітних хвиль та підтверджено, що метали можуть відбивати такі хвилі. Далі напередодні 2 світової війни була розроблена концепція RADAR (RAdio Detection And Ranging), яка згодом була реалізована і впроваджена американцями для відслідковування переміщення повітряних суден.

Для відслідковування використовувалися Первинний (PSR) і Вторинний (SSR) радари, які по суті шляхом радіохвиль, випущених в небо, “опитували” літаки і отримували від них інформацію (вторинний запровадили, зокрема, для розпізнавання свій-чужий через здатність обробляти більше даних). Такі радари використовуються і зараз. Розміщені, наприклад, в аеропортах.

Транспондер – це пристрій, який використовується на борту кожен раз, коли відбувається політ. Він шле сигнал з інформацією кожного разу, коли отримує на це запит від радару.

Transponder mode (режим транспондера) – це конкретний спосіб, у який транспондер може комунікувати з Центром контролю польотів (ЦКП) та іншими літаками. 

Transponder code (або squawk) – код, який ЦКП надає літаку для ідентифікації. Пілот вводить цей код в транспондер. Коли транспондер отримує запит на інформацію, він відповідає цим кодом, що допомагає ЦКП відрізняти цей літак від інших на екрані радару.

У цивільній авіації використовуються три основних режими транспондера:

• Mode A – самий базовий. Він лише надсилає squawk, що допомагає ідентифікувати літак та його орієнтовне положення в просторі.
• Mode C – найбільш поширений. Передає барометричну висоту (атмосферний тиск).
• Mode S (select) – більш сучасний, просунутий спосіб комунікації. Окрім того, що передають A і C, передає багато різної інформації:
  • squawk (як Mode A)
  • барометричну висоту (як Mode C)
  • hex (або icao) код
  • за допомогою GPS: координати, швидкість, висоту, курс
  • та інше

Зазвичай Mode A і Mode C використовуються разом і називаються просто Mode C. При такій взаємодії радар шле запит на всі літаки в “полі зору” і відповіді від них приходять всі на купу. Mode-S проводить вибіркове опитування повітряних суден. Такі радари взаємодіють між собою для більш точного визначення положення літака (триангуляція) і уникнення надмірного опитування (багато радарів у жвавих районах). При роботі Mode S для ідентифікації літака використовується унікальний hex (icao) код, який присвоюється літаку Міжнародною організацією цивільної авіації (ICAO) відповідно до країни реєстрації і за нормальних умов може змінюватися лише при зміні реєстрації (набір squawk вже вичерпано через обмеженість розміру даних). Фактично мінімальна мета у всіх трьох режимів – ідентифіковувати всіх учасників повітряного простору на екрані радара і запобігати зіткненням. Описане наглядно пояснено на відео від розробників Mode-S. 

Розрахунок орієнтовного положення літака в цих випадках (поки що без врахування GPS даних в Mode S) відбувається за технологією MLAT на основі кутового положення променя антени в момент передачі сигнала на літак, барометричної висоти літака, яку він передає у відповідь, і часу між отриманням двох сусідніх відповідей від літака.   

ADS-B (Automatic Dependent Surveillance-Broadcast) – це найбільш сучасна розширена система взаємодії, побудована на основі Mode-S, яка робить таку взаємодію надзвичайно цінною. Тут принципово інший підхід, оснований на тому, що літак сам постійно транслює дані про себе, без потреби, щоб його хтось опитував. Це відбувається в авто режимі (без залучення пілота чи контролера польотів) і показники, що передаються, знімаються з бортових приладів. Важливу роль у цій системі відіграє GPS, адже борт використовує її для визначення координат, висоти, напряму і навіть швидкості (у комбінації з показниками бортових приладів).

Коли країни Балтії говорять про проблеми з авіа навігацією через те, що русня глушить GPS з Калінінградської області, мова якраз про викликані цим проблеми в роботі Mode S та ADS-B.

У наші дні більшість літаків постійно транслюють повідомлення ADS-B. Починаючи з 2020 року, літаки цивільної авіації в Європі та США повинні відповідати вимогам ADS-B. Детально та доступно про ADS-B у відео або статті. До речі, протокол ADS-B дозволяє отримувати дані і в зворотньому напрямі, завдяки чому пілоти дізнаються, наприклад, про погодні умови. 

Принциповий важливий для нашої роботи момент. Mode C та Mode-S (без ADS-B), потребують наявності SSR радарів, які “опитують” борти. А от ADS-B повідомлення літак транслює самостійно, отримувати і обробляти їх може будь-хто, в кого є ADS-B ресівер. В той час, як радари розміщені лише в спеціалізованих місцях (аеропорти, військові бази і тд), ADS-B ресівер може бути куплений і встановлений ким завгодно і де завгодно. Саме завдяки нарощуванню світової мережі таких ресіверів працюють сервіси типу Flightradar24.

Проблеми моніторингу в FR24

Умовно, маємо таку картину.

Якщо ви сучасний цивільний літак, або хочаб просто слухняний літак, то ви літаєте з ADS-B, постійно транслюючи дані про себе:

• Номер хвоста (реєстраційний номер, прив’язка до країни реєстрації)
• Тип літака
• Номер рейсу
• Маршрут: звідки і куди (аеропорти)
• Callsign (змінний позивний, вводить пілот, часто  = номер рейсу)
• Координати, висоту, кут, курс, різні швидкості (залежність від GPS), тиск
• Компанію перевізника
• Обов’язковий унікальний hex (icao) код літака (прив’язка до країни реєстрації) і squawk-код транспондера (видається ЦКП, прив’язка до регіону польотів)
• Навіть час вильоту і приблизний час прильоту

Всі ці дані може отримувати будь-який ADS-B ресівер. Завдяки ним ми спостерігаємо такі літаки на сервісах, подібних Flightradar24, і політ такого літака виглядає ось так:

В будь-якій точці маршруту, окрім пунктирної лінії, видно всі дані, які система накопичила через ADS-B повідомлення від літака. Там, де пунктирна лінія, ресіверів не було – адже це над морем – тому і даних в нас не буде.

Тепер уявімо, що ви неслухняний, наприклад, військовий, підсанкційний чи якийсь іще секретний літак. Тоді ви “понижуєте” режим роботи транспондера до мінімально допустимого Mode C (?) або обмежуєте роботу Mode S (виключити GPS?) і таким чином мінімізуєте передачу даних про себе. Немає ADS-B трансляції – немає повних реалтайм даних про політ на Flightradar24 (чи подібних). У першому випадку Mode C гарантує передачу squawk коду за запитом, а в другому – Mode-S додатково до squawk передає hex-код літака. В обох випадках SRS радар ідентифікує літак, пов’язуючи коди з його хвостовим реєстраційним номером. На основі даних про барометричну висоту, яка також передається в обох випадках, радар може визначити положення літака, але для визначення його координат потрібні дані мінімум з 3х радарів (Пам’ятаєте про триангуляцію?). Враховуючи специфіку розміщення та поширення радарів, можна констатувати, що їх покриття не таке широке, як у ADS-B, та ще ж можна обирати такий маршрут, щоб спеціально оминати зони моніторингу. Маршрут такого літака складається скоріше не з ліній, а з точок, які система звісно з’єднує в пунктирні лінії, але тут скоріше можна говорити лише про оцінку маршруту після отримання хоча б 2 точок, ніж про реалтайм моніторинг. Приклади маршрутів такого літака:

Ще:

Або навіть отак:

Мій улюблений ось цей:

Тепер повернемося до моніторингу.

Flightradar24 надає підписку на інформування про потрібні борти. Фактично він просто надсилає алерт, коли розпочався черговий рейс потрібного літака, а потім ще, якщо щось в даних літака змінилося. Алерт містить хвостовий реєстраційний номер літака, номер рейсу, тип літака і посилання на “політ” на сайті системи.

Якщо перейти за посиланням, то можна побачити, як літак летить в реалтайм. Або, якщо політ завершено, подивитись вже збережені історичні дані про нього. Різна підписка надає тут різну глибину доступу до даних в минулому (фрішна – 7 днів, сілвер – 90 днів, голд – рік). Це дуже зручно. Для роботи зі слухняними літаками.

Але наша ціль – неслухняні літаки. І тут починаються проблеми.

Ось ви отримали алерт про такий літак. Там є хвостовий номер, тип літака, може є номер рейсу. І посилання на сайт. Ви допили свій чай, клікаєте по посиланню, а такого рейсу в небі нема. А де ж він дівся? А він же ховається. Фактично система вловила момент, коли літак проявився через SRS радари, і проінформувала вас, надавши лиш базові дані. В момент, коли ви перейшли за посиланням, щоб подивитися інші дані, літак в небі не спостерігається, тому для системи такого реалтайм рейсу не існує. І все. Деталі вам не доступні до наступного такого моменту, коли вам треба встигнути відкрити посилання. А це може статися в момент, коли ви до цього зовсім не готові.

Наше рішення

Збір доступних даних без втрат

Моніторинг, подібний до того, що надає підписка FR24, можна налаштувати самостійно через їх API. У FR24 є запит, який за переліком хвостових номерів літаків надає всі наявні дані по всіх літаках зі списку, які зараз в небі і віддають дані. До параметрів запиту можна додати перелік ідентифікаторів аеропортів (IATA/ICAO) і отримати з цих літаків лиш вибірку тих, які прямують з/в потрібний аеропорт. Тут для кожного аеропорту можна вказати, що саме цікавить: вильоти з нього, прямування в нього чи обидва напрямки. Взагалі серед параметрів запиту є все, що містить ADS-B повідомлення. Тому фільтрувати небо можна як завгодно. 

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

Працюючи з API ми звернути увагу, що набір даних неслухняного літака може змінюватися з часом польоту. Наприклад, коли літак вилетів, можуть бути не вказані його аеропорт вильоту, аеропорт призначення, позивний, орієнтовний час прибуття, іноді навіть рейс. Але в процесі польоту такі дані проявляються. Якщо моніторити рейс за допомогою сайту і email-алертів FR24, такі деталі вловити складно (хіба що вручну вивчати дані про політ після завершення рейсу). Раніше ми просто записували первинний прояв літака з бідним набором даних і все, вважаючи, що більше даних отримати не вдастся. За допомогою API ми постійно моніторимо прояви літака протягом рейсу і доповнюємо збережені дані новими, як тільки вони додаються. Наша система в такому випадку надсилає в канал уточнюючий алерт, який містить необхідні дані, навіть, якщо в наступний момент сигнал від літака втрачається.

Визначення прихованих аеропортів

В нашому кейсі найважливішими даними є аеропорти. Нам цікаво звідки і куди літає кожен літак зі списку і як часто він це робить. Але в більшості випадків один або обидва аеропорти залишаються прихованими.

Тут в нас кілька цікавих рішень.

Оцінка за координатами

Так чи інакше для кожного літака існує перший прояв в системі, можливо кілька наступних і точно буде останній (малоймовірно співпадатиме з першим). Під час кожного прояву ми отримуємо координати літака. В нас також є база координат потрібних аеропортів (насправді, це публічна і вже зібрана до купи інформація). Коли наша система фіксує перший прояв літака, вона за координатами визначає найближчий до нього аеропорт і такий аеропорт ми вважаємо ймовірною точкою відправлення, якщо інша явно не задана. Далі, протягом польоту, ми фіксуємо координати кожного прояву і найближчий аеропорт до них. Таким чином визначений для останнього прояву аеропорт вважаємо ймовірною точкою призначення, якщо інша явно не задана. Звісно, це дуже приблизна оцінка. Тому ми робимо додаткову валідацію: перевіряємо висоту польоту літака і його вертикальну швидкість в точці прояву. Якщо літак надто високо як для етапу зльоту/посадки, або його вертикальна швидкість занизька для цього, то малоймовірно, що цей аеропорт варто вважати аеропортом вильоту/призначення.

Оцінка за патернами

Другим кроком для уточнення даних про аеропорти рейсу ми використовуємо патерни руху бортів, складені за історичним даними. Ми зібрали дані про рух наших літаків за рік і виділити маршрути, за якими вони літають. Також пошук патернів відбувається і серед вже зафіксованих нами перельотів. Зазвичай, хоча і не обов’язково, один і той же маршрут має однаковий номер рейсу, хоча рейси при цьому незалежні і рознесені в часі.

Тому, навіть якщо десь ми не мали аеропорт(ів), але знали номер рейсу, ми дивилися аеропорт(и) цього рейсу в попередніх історичних даних, уточнюючи таким чином маршрут. Результат – перелік достатньо конкретних маршрутів по кожному літаку.

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

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

Тут orig і dest – це коди аеропортів вильоту і призначення відповідно для одного і того ж літака. Ми бачимо, що літак перелетів з UTN невідомо куди, а потім наступним рейсом повернувся з GOM в UTN. Логічно припустити, що невідомий пункт призначення в першому рядку – це GOM.

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

Тут orig і dest – це коди аеропортів вильоту і призначення відповідно для одного і того ж літака. Ми бачимо, що перші 3 рядки “розповідають” ту ж історію, що останні 3: літак вилетів з UTN невідомо куди, потім перелетів ще невідомо куди, а потім перелетів з GOM назад в UTN. В другому і п’ятому рядку однаково визначаємо, що невідомий пункт призначення – це GOM.

API ADSBx

Сервіс ADS-B Exchange вважається найбільшим світовим комьюніті сирих нефільтрованих ADS-B/Mode S/MLAT даних. Саме він стоїть на першому місці в статті про моніторинг літаків на сайті Global investigative journalism network. Важливою перевагою, про яку заявляють як в статті, так і сам сервіс, є те, що вони не приховують дані за запитом регулятора. Зокрема, сам сервіс підкреслює, що FR24 це робить. Тому ми вирішили дослідити можливості сервісу на предмет реалізації подібного нашому рішення для моніторингу.

Фактично все, що робить сервіс, це кожні 5 секунд зберігає всю картину неба = всі ADS-B дані про всі літаки, що є в небі на момент фіксації. У них є такі дані з 2020 року. І зараз збираються в реальному часі. З 2016 до 2020 дані збиралися кожні 60 сек. Далі на основі цих даних сервіс пропонує кілька варіантів співпраці.

Historical data

Сервіс надає історичні дані, які зберігає в json форматі.

Каталог всіх даних: рік – місяць – день – список файлів, кожен з яких містить дані про всі літаки в небі на конкретний момент що-5-секундного моніторингу (файли нумеруються 0, 5, 10,.. тобто можна відібрати файли за конкретний проміжок часу). Рахуємо 24 год = 1440 хв = 86400 сек = 17280 файлів за добу. Приблизна вага файлу 600 кб, тобто день важить приблизно 10 гб.

Каталог trace файлів літаків – файлів зі слідом кожного літака за конкретну добу: рік – місяць – день – файли літаків, розбиті по папках відповідно останнім цифрам hex кодів. Кожен файл містить в назві hex код свого літака, а всередині весь його слід за 24 години у форматі json. Вага файлу від кількох десятків до кількох сотень кб.

В планах у сервісу надавати дані про операції, тобто про зльоти і приземлення, у подібному структурованому вигляді.

Безкоштовно для демо надаються дані за перше число кожного місяця. Також, враховуючи великі розміри даних, сервіс пропонує вигрузку потрібної частини у хмару замовника (вибір серед кількох загальновідомих).

API light

В базовій легкій версії API за 10 дол/міс можна використовувати функції визначення положення літака за його ідентифікаторами (reg, icao, squawk, call sign), а, також “дивитись” літаки в небі в заданому радіусі (до 250 морських миль, приблизно до 500 км) від заданої точки. Це все. Щоразу функції повертають всі наявні дані по літаку(-ам). 

Для нашої задачі ми могли би регулярно “опитувати” простір навколо кожного аеропорта, що нас цікавить, і в результатах шукати літаки, що нас цікавлять. Тут кількість запитів для отримання таких даних буде дорівнювати кількості аеропортів у списку. Ми не маємо можливості визначити, літак прилетів, чи відлітає, не бачимо маршрутів. За зібраними в базі даними про перебування літака в тому чи іншому аеропорті в часі можна шукати патерни. Виглядає занадто складно. Для порівняння у FR24 ми робимо все це за 1 запит. 

Цей пакет API має свої обмеження:

• Лиш не комерційне використання по полісі
• За 10 дол/міс маємо 10 тис запитів, а це приблизно по 300 в день або по 30 в годину. Для порівняння, з FR24 ми отримуємо інфу для кількох десятків аеропортів і кількох десятків бортів за 1 запит щохвилини, а тут нам доведеться щохвилини робити стільки запитів, скільки аеропортів у списку, та ще й з подальшим додатковим аналізом результату.
• Доплата US$0.0015/запит.

Enterprise API

Розширена версія API дає доступ до реалтайм ADS-B даних про польоти. Маємо приблизно ті самі функції, що в API light, але додатково ще кілька цікавих:

• Функція дає перелік всіх військових літаків, що трекаються в небі на момент запиту
• Функція, яка повертає trace файл літака за його hex кодом – це фактично останній (ймовірно, за останній політ чи 24 год?) слід літака у форматі json, де збережено дані літака за кожні 5 секунд моніторингу
• Функція, аналогічна попередній, повертає trace файл літака за конкретну дату в минулому (24 год = 1440 хв = 86400 сек = 17280 записів у файлі)
• Експериментальна функція – отримання операційної історії літака в проміжку часу за його icao. Формат даних стандатний – json, де збережено дані літака за кожні 5 секунд моніторингу. Доступна лиш бета версія
• Експериментальна функція, аналогічна попередній, повертає операційну історію аеропорта в проміжку часу за його кодом. Історія містить інформацію про зльоти і приземлення літаків, надаючи повні дані по ним. Доступна лиш бета версія

Що ж, тут маємо достатньо корисні сирі дані в максимальній кількості. І не маємо обмежень API light. Особливо важливо, що маємо структуровані історичні дані про літаки і аеропорти. За запитом обіцяють дати тестовий доступ.

FR24 vs ADSBx

Резюмуємо. Автоматично моніторити реалтайм дані за допомогою FR24 значно зручніше, ніж з ADSBx, завдяки зручному і універсальному API. Стосовно історичних даних FR24 надає лиш ручний доступ за підпискою, а от у ADSBx є кілька варіантів на будь який смак: безкоштовний ручний доступ (в панелі справа шукаєте літак, в панелі зліва дивитесь історію), база із що-5-секундною картиною неба, trace файли із слідом кожного літака за дату чи період, і найбажаніше – поки що в бета тестуванні, але вже доступні за домовленістю після оплати функції API про операції по літаку і по аеропорту. Робота з сирими історичним даними в файлах сильно ускладнена кількістю записів і об’ємом самих файлів. Нам не вдалося отримати бажаний результат навіть за доступними демо даними. Для нашої кількості літаків і аеропортів простішим виявилося зібрати дані з FR24 за рік вручну.