Реализация предиктивного обслуживания оборудования (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 для scheduled inference) + TimescaleDB для хранения телеметрии.
На уровне ML: модель аномалий обучается на исторических данных нормальной работы оборудования. Чаще всего применяем Isolation Forest для первичного детектирования и LSTM Autoencoder для более точной классификации типа аномалии. Модели экспортируются в ONNX для унификации инференса.
Порог алерта настраивается на уровне устройства, а не глобально — один и тот же насос в разных условиях эксплуатации даёт разный базовый уровень вибрации.
Процесс работы
Начинаем с аудита: какие датчики, протоколы, объём данных, требуется ли offline-режим. Затем — прототип интеграции с реальным оборудованием (без этого оценка сроков бессмысленна). Параллельно — сбор исторических данных для обучения модели.
Разработка идёт итерациями: сначала вывод сырых данных в приложение, потом графики, потом алерты по пороговым значениям, потом ML-алерты. Каждый этап проверяется с техниками на реальном объекте.
Ориентиры по срокам
MVP с подключением к одному типу датчиков, дашборд и пороговые алерты — 4–6 недель. Полноценная система с ML-моделью, несколькими типами оборудования, offline-режимом и интеграцией с ERP — 3–5 месяцев. Стоимость рассчитывается индивидуально после анализа инфраструктуры и требований к точности прогнозирования.