AI-аналітика безпеки авіації: FOQA та предиктивне обслуговування
Щомісяця через FOQA проходять сотні рейсів, але аналітики вручну перевіряють лише малу частину. Типова авіакомпанія з парком у 50 ПС генерує до 10 000 параметрів на секунду — ручний аналіз такої щільності даних неможливий. Залишається масив даних FDR/QAR, де приховані ранні сигнали ризику: нестабілізовані заходи, зростання EGT, пікові g-load. Ми автоматизуємо розбір 100% політних даних, об'єднуючи часові ряди параметрів, ACARS-повідомлення та ATC-транскрипти. Рішення на основі LSTM Autoencoder та fine-tuned BERT детектує аномалії на 40% швидше за традиційні методи та скорочує час аналізу на 90%. У цьому розділі розберемо, як гібридний підхід, що поєднує rule-based детекцію та глибоке навчання, допомагає ловити ланки «ланцюжка Хайнріха» до того, як вони замкнуться. Як стандарти використовуємо ICAO Annex 6 та EASA AMC20-29, а весь pipeline розгортається на інфраструктурі замовника.
Які проблеми вирішує AI-система безпеки польотів?
Розрізнені джерела даних — часта причина втрачених ризиків. FOQA-звіти вибіркові, ATC-переговори не аналізуються, а тренди деградації двигунів помічають лише при відмові. Наш підхід закриває ці прогалини:
-
Пропущені перевищення. Ручний аналіз пропускає до 80% нестабілізованих заходів. Алгоритм на основі ковзних вікон з фільтром Савицького–Голея детектує навіть короткочасні відхилення.
-
Пізнє виявлення деградації двигунів. EGT margin знижується поступово — LSTM Autoencoder передбачає відмову за 60 циклів до неї. Типова економія на одному двигуні може досягати 120 000 за рахунок відсутності AOG.
-
Невикористані текстові дані. ATC-транскрипти — скарбниця предикторів. BERT, fine-tuned на авіаційному корпусі, знаходить патерни «say again» та «unable» за секунди. Ми також впроваджуємо RAG — векторне сховище ChromaDB для швидкого пошуку релевантних процедур та стандартів. Для аналізу застосовуємо LLM та вміємо налаштовувати few-shot промпти під конкретні авіакомпанії.
Чому гібридний підхід ефективніший за чистий ML?
Чисті ML-моделі часто дають хибні спрацювання на шумних даних. Гібрид: правила ловлять 80% типових подій, нейромережа — 20% рідкісних аномалій. Порівняння:
| Метод |
Частка подій |
Точність |
Витрати на обчислювальні ресурси |
| Rule-based |
80% |
97% |
Низькі |
| ML (LSTM Autoencoder) |
20% |
95% |
Середні |
| Гібрид |
100% |
96% |
Оптимальні |
Наш кейс із практики: авіакомпанія-перевізник, 24 літаки B737NG/A320. До впровадження FOQA аналізували вибірково — 5% рейсів. Після автоматизації: 100% рейсів, 8 типів подій. За перші 3 місяці виявлено 340 нестабілізованих заходів (з них 38 — із значними відхиленнями), 7 жорстких посадок вище порогу інспекції, деградація EGT margin на двох двигунах передбачена за 60 циклів до планової заміни гарячої секції. Система підняла один двигун на позапланове зняття — виявлено тріщини compressor blade.
Стек:
| Шар |
Технології |
| Прийом FDR/QAR |
ARINC 717/767 парсери, Python |
| Часові ряди |
pandas, scipy, stumpy (matrix profile) |
| Аномалії двигунів |
LSTM Autoencoder (PyTorch) |
| NLP переговорів |
BERT fine-tuned на авіакорпусі |
| RAG-сховище |
ChromaDB з embeddings 1536-dim |
| Зберігання |
TimescaleDB (часові ряди) |
| Дашборд |
Grafana + кастомний React |
| Стандарти |
ICAO Annex 6, EASA AMC20-29, IS-BAO |
Деталі архітектури LSTM Autoencoder
Архітектура складається з LSTM-кодувальника з 3 шарами (hidden size 128, 64, 32) та декодувальника симетрично. Вхід — вікно з 64 часових кроків багатовимірного ряду (тиск, температура, вібрація). Поріг аномалії — 95-й перцентиль MAE на валідації. Використовуємо dropout 0.2, learning rate 1e-3.
Як LSTM Autoencoder передбачає відмови двигунів?
Модель навчається на багатовимірних часових рядах параметрів двигуна (EGT, вібрація, тиск масла) в нормальному стані. При появі аномалії реконструкція різко погіршується — MAE перевищує поріг. Це дозволяє виявити деградацію за 60 циклів до відмови, що дає час на планування ремонту без AOG.
Процес роботи
- Аналітика. Збираємо вимоги до параметрів, типи ПС, існуючі SOP. Аудит якості даних (пропуски, шуми).
- Проектування. Визначаємо пороги подій, вибираємо архітектуру ML-моделей, налаштовуємо pipeline завантаження.
- Реалізація. Розробляємо парсери FDR, детектори аномалій, NLP-модуль. Інтегруємо з ACARS та MRO-системами.
- Тест. Валідуємо на історичних даних: precision/recall не нижче 95%. Проводимо юзабіліті-тестування дашборду.
- Деплой. Розгортаємо на інфраструктурі замовника (on-prem або cloud). Навчаємо команду, передаємо документацію.
Що входить в роботу
- Парсер FDR/QAR під ваш тип ПС.
- Інтеграція з ACARS та MRO-джерелами.
- Дашборд Grafana з фільтрацією за рейсами, типами подій, часовими вікнами.
- NLP-модуль аналізу ATC-транскриптів.
- Модель предиктивного обслуговування двигунів (LSTM Autoencoder).
- Навчання двох спеціалістів замовника.
- Технічна підтримка 3 місяці після запуску.
Терміни орієнтовно
Базовий FOQA аналізатор параметричних подій — від 6 до 8 тижнів. Повний стек з NLP, предиктивним обслуговуванням двигунів та дашбордом — від 4 до 5 місяців. Вартість розраховується індивідуально під обсяг парку та глибину інтеграції. Оцінимо проект за 2 дні — зв'яжіться з нами.
Типові помилки при впровадженні
- Використовувати лише один метод (rules або ML). Правило: 80% простих подій — rules, 20% складних — ML.
- Ігнорувати шум датчиків: без згладжування Savitzky–Golay false positive досягає 30%.
- Не налаштовувати пороги під тип ПС: для A320 та B737 пороги по g-load відрізняються на 0.3g.
Ми гарантуємо точність виявлення аномалій не менше 95% на валідації. Досвід: понад 15 проектів для парків від 10 до 100 ПС. Отримайте консультацію — ми проаналізуємо ваш поточний FOQA-процес та запропонуємо рішення. Замовте демонстрацію дашборду, щоб побачити, як алгоритми працюють на ваших даних.
Виявлення аномалій: автоенкодери, Isolation Forest, PyOD
Ми стикаємося з цим болем постійно: моніторинг сервера показує CPU 85%, пам'ять 91% — це норма в годину пік чи початок атаки? Класифікатор тут не допоможе: аномалії за визначенням рідкісні, різноманітні та заздалегідь не розмічені. Supervised learning потребує прикладів аномалій у навчальній вибірці — а значить, не працює для того, про що ви ще не знаєте. Наш досвід показує: без unsupervised-підходу виявлення перетворюється на гадання.
Чому виявлення аномалій потребує unsupervised підходу?
Головна проблема — відсутність розмітки та дисбаланс класів в екстремальній формі. Фрод-транзакції становлять 0.01–0.1% від загального об'єму. Виробничий дефект — 0.5–3%. При такому співвідношенні навіть наївний класифікатор «все нормально» дасть accuracy 99.9% і precision/recall для аномального класу, близькі до нуля. Supervised-моделі тут безсилі.
Друга проблема — «нормальність» завжди контекстна. Чи нормально, що користувач логіниться о 3 годині ночі? Залежить від його історії та часової зони. Чи нормальна вібрація підшипника 2.3 мм/с? Залежить від режиму роботи верстата та його віку. Тому ми вбудовуємо контекст у модель через feature engineering та часові вікна.
Третя — оцінка якості. Немає стандартного test set, AUC-ROC вважається тільки якщо є хоча б трохи розмічених прикладів. На повністю нерозмічених даних — тільки domain expert validation та непрямі метрики.
Як відрізнити аномалію від шуму в реальному часі?
Відповідь — адаптивні пороги та моніторинг статистик моделі. У розділі кейсу покажемо, як це працює.
Методи та інструменти
| Метод |
Тип даних |
Швидкість навчання |
Типове застосування |
| Isolation Forest |
Табличні, категоріальні |
Висока |
Baseline для перших гіпотез |
| Autoencoder |
Зображення, часові ряди, логи |
Середня |
Неструктуровані дані |
| LSTM-AE |
Багатовимірні часові ряди |
Низька |
Промислова телеметрія |
| PyOD (ансамбль) |
Табличні |
Висока |
Швидке порівняння 40+ методів |
Isolation Forest — стандартний baseline для табличних даних. Ідея: аномалії ізолюються швидше при випадковому розбитті простору ознак. Працює добре при contamination 0.01–0.1, стійкий до масштабу ознак, не потребує нормалізації. Реалізація в sklearn.ensemble.IsolationForest.
Типова помилка: ставити contamination='auto' без розуміння даних. Auto-режим передбачає поріг -0.5, що не завжди відповідає реальній частці аномалій. Краще: оцініть очікуваний відсоток аномалій через domain knowledge і задайте явно. Ми гарантуємо підбір contamination під ваш кейс.
PyOD (Python Outlier Detection) — бібліотека з 40+ алгоритмами під єдиним API. Включає: OCSVM, LOF, COPOD, ECOD, DeepSVDD, AutoEncoder. Зручно для швидкого порівняння методів на одних даних.
Автоенкодери — основний метод для неструктурованих даних (часові ряди, зображення, логи). Ідея: навчаємо мережу відновлювати нормальні дані, аномалії дають високу помилку реконструкції. Поріг аномальності — 95-й або 99-й процентиль помилки на validation set з нормальних даних.
Практична проблема автоенкодерів: переучування на «нормальних» паттернах, які все одно зустрічаються рідко. Якщо в train set є хоча б кілька аномалій, модель може навчитися їх добре відновлювати. Рішення: ретельне очищення training data або використання Variational Autoencoder (VAE), який краще узагальнює.
LSTMAE для часових рядів — LSTM-автоенкодер захоплює часові залежності краще, ніж звичайний AE. Особливо ефективний для мультиваріантних часових рядів (10+ сенсорів одночасно). Реалізація через PyTorch, навчання з MSELoss на ковзних вікнах.
Детально: виявлення аномалій у промислових часових рядах
Задача: вібраційні датчики на 12 насосах хімічного підприємства, 6 сенсорів на насос, частота 100 Гц. Потрібно попередити про наближену поломку за 4–24 години.
Архітектура рішення:
Сирові дані → feature extraction (RMS, куртозис, піковий фактор, FFT-амплітуди на резонансних частотах) → нормалізація по ковзному вікну 24 год → LSTMAE → reconstruction error → порогова логіка + алертинг.
Розмір вікна LSTM: 60 секунд (6000 точок на 100 Гц). Занадто мале вікно — не захоплює повільні паттерни. Занадто велике — втрачає чутливість до швидких змін.
Поріг аномальності: не фіксований, а адаптивний. threshold = mean(errors_last_7d) + 3 * std(errors_last_7d). При дрейфі нормального стану (плановий знос) поріг адаптується, уникаючи false positives.
Результат на 6-місячному пілоті: виявлено 4 з 5 реальних передвідмовних станів (recall 0.8), 2 хибні тривоги за 6 місяців (precision 0.67). До впровадження: 3 незаплановані зупинки зі значними збитками. Економія після впровадження — значна сума за півроку (звіт про пілот на об'єкті клієнта).
Фрод-детекція: специфіка фінансових даних
Фінансові транзакції мають кілька особливостей, що ускладнюють виявлення:
- Concept drift: паттерни фроду змінюються швидше нормальної поведінки. Модель, навчена півроку тому, застаріває.
- Adversarial adaptation: просунуті шахраї адаптуються до виявлення — роблять транзакції схожими на нормальні.
- Часова залежність: серія нормальних транзакцій, а потім один незвичайний переказ — це аномалія послідовності, а не одиничної точки.
Практичний стек для фрод-детекції: LightGBM з SMOTE-oversampling для supervised частини (за відомими фрод-кейсами) + Isolation Forest для unsupervised (нові паттерни). Обидва сигнали об'єднуються в ансамбль, фінальне рішення — через пороги, налаштовані на прийнятний FPR (0.1–1% від транзакцій на ручну перевірку).
Як оцінити якість без розмітки?
Коли ground truth немає, для оцінки використовуємо:
- Synthetic anomaly injection: додаємо штучні аномалії (spike, level shift, point outlier) і дивимося, чи виявляє їх модель
- Expert validation: випадкова вибірка топ-K аномалій від моделі → review експерта → precision
- Business metric: чи знизилася кількість пропущених інцидентів / хибних тривог після впровадження
Технічна деталь: налаштування адаптивного порогу
Поріг обчислюється як mean(errors) + k * std(errors) на ковзному вікні 7 днів. Коефіцієнт k підбирається на validation set з синтетичними аномаліями для досягнення FPR < 0.1%. При дрейфі ознак вікно автоматично зсувається.
Процес роботи
-
Інтерв'ю з доменними експертами — розуміємо, що таке «нормальність» і які інциденти вже були.
-
EDA та підготовка даних — очищення, створення ознак, часові вікна.
-
Baseline (Isolation Forest) — швидка валідація на відомих інцидентах.
-
Вибір та кастомізація моделі — Autoencoder / LSTM-AE / ансамбль.
-
Навчання, валідація з синтетичними аномаліями.
-
Розгортання в production — пайплайн на Kafka + Flink / Airflow, алертинг в Telegram/Slack, моніторинг дрифту.
-
Post-deployment супровід — моніторинг метрик моделі, оновлення порогів.
Що входить у роботу
- Аудит поточних даних та процесів
- Розробка та навчання моделей (Isolation Forest / Autoencoder / LSTM-AE / ансамбль)
- Налаштування адаптивних порогів та алертингу
- Панель моніторингу аномалій (Grafana / Streamlit)
- Документація model card та pipeline
- Навчання вашої команди (2–3 сесії)
- Гарантійна підтримка 3 місяці
Терміни: baseline-система з одним методом — 2–4 тижні. Production-система з адаптивними порогами, алертингом та моніторингом — 2–5 місяців. Вартість розраховується індивідуально під ваш кейс.
Наша команда має 8+ років досвіду в промисловій аналітиці та 15+ успішних проектів з виявлення аномалій в телеметрії, фінансах та IT-моніторингу. Отримайте консультацію — розкажемо, як вирішити вашу задачу.