Реалізація предиктивного обслуговування обладнання (Predictive Maintenance) у мобільних додатках
Predictive Maintenance у мобільному контексті — це не просто дашборд з графіками. Це система, яка збирає дані з датчиків (вібрація, температура, струм), пускає їх через ML-модель та видає прогноз відмови до того, як обладнання встане. Мобільний додаток тут виступає як інтерфейс для техніків у полі: вони отримують алерт, відкривають карточку обладнання, бачать аномалію на тренді та приймають рішення про заміну вузла.
Де дійсно складно
Збір даних з обладнання. Датчики відправляють дані через різні протоколи: Modbus RTU/TCP, OPC-UA, MQTT, іноді BLE. Мобільний додаток рідко спілкується з ними напрямо — зазвичай є edge-сервер (Raspberry Pi, Siemens IoT2040), який збирає дані та пушить їх в хмару. Завдання додатка — підписатися на MQTT-топіки або polling REST API та правильно обробити пропуски в телеметрії (датчик відвалився на 2 хвилини — це не аномалія, це розрив зв'язку).
На Android підписка на MQTT зручно тримається в ForegroundService з постійним сповіщенням — це єдиний спосіб гарантувати отримання даних у реальному часі без убивання процесу агресивними battery savers на Xiaomi та Huawei. Використання WorkManager для MQTT — помилка: він не гарантує інтервали менше 15 хвилин.
Візуалізація часових рядів. Відображення 10 000 точок на графіку вібрації — це не виклик drawLine у циклі. На iOS Charts (колишній danielgindi/Charts) погано переварює більше 2 000 точок без прорідження. Рішення: LTTB (Largest-Triangle-Three-Buckets) — алгоритм downsampling, який зберігає візуальну форму кривої при зменшенні числа точок у 10–20 разів. Реалізується на стороні клієнта перед рендером.
ML-модель: на сервері або on-device? Для промислових систем модель зазвичай живе на сервері — обсяг даних та складність (LSTM, Isolation Forest, XGBoost) передбачають серверний inference. Але якщо об'єкт у зоні без інтернету (шахта, віддалене родовище), потрібен on-device варіант. CoreML на iOS та TFLite на Android справляються з полегшеними моделями (pruned LSTM, ONNX-конвертований Random Forest). Модель оновлюється при появі мережі через фонове завантаження.
Як ми це будуємо
Типовий стек: мобільний додаток (React Native або Flutter для кросс-платформи, Swift/Kotlin для нативних вимог) + MQTT клієнт (Eclipse Paho або mqtt_client для Flutter) + бекенд на Python (FastAPI + Celery для планового inference) + TimescaleDB для зберігання телеметрії.
На рівні ML: модель аномалій навчається на історичних даних нормальної роботи обладнання. Найчастіше застосовуємо Isolation Forest для первинного детектування та LSTM Autoencoder для точнішої класифікації типу аномалії. Моделі експортуються в ONNX для унітарізації inference.
Поріг алерту налаштовується на рівні пристрою, а не глобально — один і той же насос у різних умовах експлуатації дає різний базовий рівень вібрації.
Процес впровадження
Починаємо з аудиту: які датчики, протоколи, обсяг даних, потрібен ліле офлайн-режим. Потім — прототип інтеграції з реальним обладнанням (без цього оцінка строків безсмислена). Паралельно — збір історичних даних для навчання моделі.
Розробка йде ітераціями: спочатку вивід сирих даних у додаток, потім графіки, потім алерти за пороговими значеннями, потім ML-алерти. Кожен етап перевіряється з техніками на реальному об'єкті.
Часові орієнтири
MVP з підключенням до одного типу датчиків, дашборд та пороговідні алерти — 4–6 тижнів. Повноцінна система з ML-моделлю, кількома типами обладнання, офлайн-режимом та інтеграцією з ERP — 3–5 місяців. Вартість розраховується індивідуально після аналізу інфраструктури та вимог до точності прогнозування.