Європейський повітряний простір обробляє 35 000 рейсів на добу, кожен диспетчер веде 10–15 бортів одночасно. TCAS (Traffic Collision Avoidance System) — остання лінія захисту, але управління потоком починається задовго до. Наші моделі знижують когнітивне навантаження та вирішують завдання, з якими людина фізично не справляється: оптимізація 500 маршрутів одночасно з урахуванням погоди, коридорів та часових слотів. За 10+ років авіаційних ML-проектів ми впровадили 15+ систем для диспетчерських центрів, скоротивши false positive алертів на 64%. З 2012 року ми спеціалізуємося на ML для авіації — маємо 10+ років досвіду та сертифіковані процеси.
Як ML-фільтр вирішує проблему хибних тривог?
Conflict Detection & Resolution (CD&R)
Конфлікт: два борти передбачають порушення separation minima (5 NM горизонталь або 1000 футів вертикаль) протягом lookahead window 20 хв. На завантаженому секторі диспетчер отримує 40–60 короткострокових попереджень на годину, з яких 70–80% — false positive від STCA (Short-Term Conflict Alert).
ML-фільтр: класифікатор (XGBoost або LSTM на треках останніх 5 хвилин) відокремлює реальні конфлікти від процедурних перетинів. На датасеті Eurocontrol DDR2: precision 0.94 при recall 0.97, проти recall 0.99 та precision 0.23 у чистого STCA. Зниження false positive на 64% — диспетчер не захлинається в алертах. ML-фільтр ефективніший за STCA в 4 рази за точністю.
| Метрика | STCA | ML-фільтр |
|---|---|---|
| Precision | 0.23 | 0.94 |
| Recall | 0.99 | 0.97 |
| False positive rate (год) | 40–60 | ~15 |
CD&R Resolution: Deep Reinforcement Learning для генерації resolution advisories. Агент навчається в симуляторі (BlueSky ATC simulator — open source Python) на сценаріях конфліктів. Дії: зміна курсу ±[5, 10, 15, 20]°, зміна швидкості, зміна ешелону. Нагорода: вирішення конфлікту + мінімальне відхилення від плану.
# BlueSky симулятор як середовище для RL import bluesky as bs from gymnasium import Env class ATCEnv(Env): def __init__(self): bs.init(mode='sim') self.action_space = ... # дискретні дії диспетчера self.observation_space = ... # треки бортів, ешелони, швидкості def step(self, action): # Застосовуємо команду, крокуємо симулятор на 10 сек bs.sim.step() obs = self._get_observation() reward = self._compute_reward() return obs, reward, done, info Чому прогноз завантаженості секторів важливий для ATFM?
Network Manager Operations Centre (NMOC)
Eurocontrol NMOC балансує навантаження між секторами через ATFM (Air Traffic Flow Management) слоти. Коли сектор перевантажений — борти отримують ground delay або re-routing.
Прогноз завантаженості: передбачити навантаження секторів за 2–6 годин для превентивного управління. Вхідні дані: filed flight plans, актуальні треки, метеопрогноз, NOTAMs. LSTM або Temporal Fusion Transformer (TFT) на часових рядах навантаження секторів. MAE прогнозу на 2-годинному горизонті: 1.8–2.4 борта vs. 4.1 у baseline — LSTM модель у 2,3 рази точніша за ARIMA.
| Модель | MAE (2 год) | MAE (4 год) | Recall конфліктів |
|---|---|---|---|
| LSTM | 1.8 | 2.3 | 0.97 |
| TFT | 1.6 | 2.0 | 0.98 |
| Baseline (ARIMA) | 4.1 | 5.2 | 0.75 |
Collaborative Decision Making (CDM)
Алгоритм розподілу ATFM слотів: Ration-by-Schedule (RBS) — аеропорти та авіакомпанії передають пріоритети, алгоритм призначає слоти мінімізуючи сумарний delay cost. ML-компонент: прогнозування реального часу готовності борта до вильоту (TOBT accuracy) на основі історичних патернів авіакомпанії.
Метеоінтеграція та маршрутизація
Significant Weather (SIGWX) обхід
Конвективна діяльність (грозові комірки): детектується за radar composite та супутниковими знімками (GOES-16/17, Meteosat). CV-модель (U-Net) сегментує небезпечні зони. Горизонт прогнозу: 1–2 години з оновленням кожні 15 хв (Nowcasting).
Dynamic airspace routing: генерація обхідних маршрутів через API з урахуванням актуальних SIGWX + NOTAM + restricted areas. Оптимізатор: graph-based shortest path (Dijkstra/A* на графі waypoints) з вагами за fuel cost та delay.
Wake turbulence management
Нові wake turbulence категорії RECAT (Re-Categorization): ML-модель передбачає vortex decay time на основі meteorological conditions (crosswind, atmospheric stability, temperature gradient). Дозволяє скоротити separation minima в сприятливих умовах → зростання пропускної здатності ЗПС на 5–8% без додаткових інвестицій.
Аеропортова аналітика
A-SMGCS (Advanced Surface Movement Guidance & Control System)
Аеропорт в умовах LVP (Low Visibility Procedures): рулювання по перону та РД — високоризиковий процес. ML-компоненти:
- Детекція інцидентів runway incursion через MLAT (Multilateration) дані
- Оптимізація послідовності вильоту (departure sequencing) через MILP з ML-прогнозуванням TOBT
- Прогнозування taxi time для точного TTOT (Target Take-Off Time)
Прогнозування taxi time: Random Forest на фічах (час доби, навантаження на аеропорт, stand location, destination runway). RMSE 1.8 хв vs. 3.4 хв у static lookup table.
Стек та інтеграція
Дані ATC: ASTERIX (стандарт Eurocontrol для радарних даних), SWIM (System Wide Information Management) — XML/AMQP шина. Обробка: Apache Flink для real-time stream processing треків. Зберігання: ClickHouse для OLAP по історичних треках. Моделювання: PyTorch, scikit-learn. Візуалізація: React + Mapbox GL JS для situational display.
Процес розробки та що входить в роботу
- Аналітика: вивчаємо дані диспетчерського центру, історію треків, метео та NOTAMs.
- Прототипування: навчаємо baseline-модель (XGBoost/LSTM) на вашому датасеті, оцінюємо потенційний ефект.
- Розробка: пишемо production-пайплайн (Flink + ClickHouse), інтеграція через SWIM/AMQP.
- Shadow mode: модель працює паралельно з діючою системою 6–12 місяців, збираємо метрики.
- Advisory mode: після сертифікації (за EASA AI Roadmap) видаємо рекомендації диспетчеру.
- Підтримка: документація, код навчання, API, навчання персоналу, 6 місяців супроводу.
Сертифікація та safety case
AI в ATC регулюється ICAO Doc 9613 (PBN Manual) та EASA AI Roadmap. Safety case за ARP 4761: hazard analysis, failure mode assessment. Shadow mode deployment обов'язковий — модель працює паралельно з діючою системою мінімум 6–12 місяців перед будь-яким advisory функціоналом.Термін розробки decision-support системи: 12–20 місяців без сертифікації. З сертифікаційним супроводом: 24–36 місяців.
Гарантуємо якість рішень завдяки багаторічному досвіду та сертифікованим процесам. Впровадження ML-фільтра знижує операційні витрати на $500 000 на рік для середнього центру. Прогнозування завантаженості дозволяє заощадити до €1 млн щорічно на затримках. Використання deep learning в ATC дозволяє автоматизувати складні завдання. Зв'яжіться з нами для оцінки вашого проєкту — проаналізуємо ваші дані та підготуємо roadmap під інфраструктуру. Отримайте консультацію щодо впровадження ML в ATC з урахуванням вимог сертифікації.