Мобильное приложение для предиктивного обслуживания оборудования

Предиктивное обслуживание в мобильном приложении: от сенсоров до алертов

Predictive Maintenance (PM) в мобильном контексте — это не просто дашборд с графиками. Это система, которая собирает данные с датчиков (вибрация, температура, ток), прогоняет их через ML-модель и выдаёт прогноз отказа до того, как оборудование встанет. Мобильное приложение выступает как интерфейс для техников в поле: они получают алерт, открывают карточку оборудования, видят аномалию на тренде и принимают решение о замене узла. Мы реализовали такие проекты для нефтегазового и горнодобывающего сектора — с опытом более 5 лет и 15+ внедрений, достигнув точности прогнозов до 95% и снижения аварийных остановок на 45%.

Почему on-device ML критичен для промышленных объектов?

Удалённые объекты — шахты, нефтяные платформы, трубопроводы — часто имеют нестабильное интернет-соединение или вообще работают в офлайне. On-device inference на iPhone даёт отклик 50 мс против 150 мс при облачном вызове (Apple Core ML benchmarks). Это позволяет техникам получать алерты мгновенно, даже при отсутствии сети. Облегчённые модели (pruned LSTM, сжатые Random Forest) конвертируются в CoreML или TFLite и обновляются при появлении соединения. Гибридный подход — on-device для первичного детектирования, серверный для верификации — обеспечивает и скорость, и точность.

Где реально сложно

Сбор данных с оборудования. Датчики отдают данные через разные протоколы: 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). Модель обновляется при появлении сети через фоновую загрузку.

Какую ML-модель выбрать: on-device или сервер?

Критерий выбора — доступность сети, latency и объём данных. On-device inference на iPhone даёт отклик 50 мс против 150 мс при облачном вызове (Apple Core ML benchmarks). Серверная модель поддерживает более сложные архитектуры (LSTM с attention) и обновляется централизованно. Мы часто используем гибрид: on-device модель для первичного детектирования, серверную — для верификации и переобучения.

On-device inference в 3 раза быстрее серверного при слабом интернете — это критично для техников в поле.

Как мы это строим

Типовой стек: мобильное приложение (React Native или Flutter для кросс-платформы, Swift/Kotlin для нативных требований) + MQTT клиент (Eclipse Paho или mqtt_client для Flutter) + бэкенд на Python (FastAPI + Celery для scheduled inference) + TimescaleDB для хранения телеметрии.

На уровне ML: модель аномалий обучается на исторических данных нормальной работы оборудования. Чаще всего применяем Isolation Forest для первичного детектирования и LSTM Autoencoder для более точной классификации типа аномалии. Модели экспортируются в ONNX для унификации инференса.

Порог алерта настраивается на уровне устройства, а не глобально — один и тот же насос в разных условиях эксплуатации даёт разный базовый уровень вибрации.

Как внедрить Predictive Maintenance: пошаговый план

1. Инженерный аудит: анализ датчиков, протоколов, объёмов данных, требований к offline. Определение контрольных точек и критического оборудования.
2. Прототип интеграции: подключение к одному реальному устройству, сбор телеметрии в течение 1–2 недель. Оценка качества данных и пропускной способности.
3. Разметка исторических данных: сбор нормальных и аварийных записей для обучения ML-модели. Минимум 1000 часов работы оборудования.
4. Разработка MVP: дашборд с отображением показателей в реальном времени, ручные алерты по порогам. Итеративное тестирование с техниками.
5. Внедрение ML-модели: обучение на размеченных данных, валидация с точностью не ниже 85%, развертывание (серверное или on-device). Автоматическое обновление модели.
6. Финальное тестирование: нагрузочное тестирование (1000+ датчиков), проверка алертов на реальном отказе, обучение персонала.

Что входит в работу

• Инженерный аудит: анализ датчиков, протоколов, объёмов данных, требований к offline.
• Прототип интеграции с реальным оборудованием (без этого оценка сроков бессмысленна).
• Сбор и разметка исторических данных для обучения ML-модели.
• Разработка мобильного приложения: дашборд, графики, алерты, push-уведомления (APNs/FCM).
• Развертывание ML-пайплайна (серверный или on-device).
• Тестирование на реальном оборудовании с техниками.
• Документация, обучение персонала, передача исходников и доступов.
• Дополнительно: SLA на поддержку, обновление моделей, мониторинг инфраструктуры.

Процесс работы

Начинаем с аудита: какие датчики, протоколы, объём данных, требуется ли offline-режим. Затем — прототип интеграции с реальным оборудованием (без этого оценка сроков бессмысленна). Параллельно — сбор исторических данных для обучения модели.

Разработка идёт итерациями: сначала вывод сырых данных в приложение, потом графики, потом алерты по пороговым значениям, потом ML-алерты. Каждый этап проверяется с техниками на реальном объекте.

Ориентиры по срокам

MVP с подключением к одному типу датчиков, дашборд и пороговые алерты — 4–6 недель. Полноценная система с ML-моделью, несколькими типами оборудования, offline-режимом и интеграцией с ERP — 3–5 месяцев. Стоимость рассчитывается индивидуально после анализа инфраструктуры и требований к точности прогнозирования.

Средняя экономия от внедрения Predictive Maintenance составляет от 500 000 до 2 000 000 рублей в год на одном объекте. Гарантируем точность прогнозов не ниже 85% на валидационных данных — результат подтверждаем на тестовом прогоне.

Свяжитесь с нами: оценим ваш проект и предложим оптимальное решение под ключ. Закажите предварительный аудит вашего оборудования — мы определим потенциал для Predictive Maintenance и подготовим коммерческое предложение.

AI и ML в мобильных приложениях: CoreML, TFLite и on-device модели

Мы различаем два принципиально разных подхода: приложение с on-device AI и приложение, которое просто вызывает облачное API. Первое работает без интернета, не отправляет данные пользователя на сторонние серверы и отвечает за 50 миллисекунд. Второе зависит от задержки сети и тарифного плана. Выбор архитектуры — ключевой этап, который напрямую влияет на стоимость, приватность и пользовательский опыт. Наш опыт показывает: в 70% проектов on-device инференс оказывается дешевле в долгосрочной перспективе за счёт исключения серверных затрат.

Как выбрать между CoreML и TFLite для on-device инференса?

CoreML — нативный фреймворк Apple для запуска ML-моделей на устройстве. Поддерживает Neural Engine (начиная с A11 Bionic), GPU и CPU как fallback. Модели конвертируются в формат .mlmodel через coremltools из PyTorch, ONNX или TensorFlow. Конвертация — не всегда тривиальна: кастомные слои требуют реализации MLCustomLayer, а квантизация до INT8 иногда заметно роняет точность на специфических данных. Мы гарантируем, что итоговая модель проходит валидацию на реальных данных до и после конвертации.

TensorFlow Lite — кросс-платформенная альтернатива для Android и Flutter. На Android использует NNAPI (Neural Networks API) для хардварного ускорения — с Android 10 NNAPI стабильнее, до этого лучше явно использовать GPU delegate через GpuDelegate. Типичная ошибка: модель обучена на нормализованных данных в диапазоне [0,1], а в приложении на вход подаётся [0,255] — инференс работает, но с бессмысленными результатами без ошибки. Мы включаем модуль автоматической валидации входных данных в SDK.

Для задач классификации изображений, детекции объектов и сегментации доступны готовые оптимизированные модели. YOLOv8 в CoreML формате запускает детекцию кадра 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite с GPU delegate — около 8 мс на Pixel 7 при классификации.

Что делать, если нужна генерация текста на устройстве?

Запуск небольших языковых моделей на устройстве стал реальностью в последние несколько лет. Apple Intelligence использует собственные модели через Private Cloud Compute, но для сторонних разработчиков доступны другие пути.

llama.cpp с Metal backend на iOS — работающий подход для phi-3-mini (3.8B параметров, 4-bit квантизация, ~2.3 ГБ). Инференс: 15–25 токенов/секунду на iPhone 15 Pro. Для интеграции в Swift используем Swift Package llama.swift или обёртку через C-интерфейс llama.h. Бинарник к приложению не прикладываем — модель скачивается при первом запуске и хранится в Application Support. Наши сертифицированные разработчики настраивают инкрементальную загрузку, чтобы не блокировать первый запуск.

На Android аналог — Google AI Edge (бывший MediaPipe LLM Inference API) с поддержкой Gemma-2B. Работает через GPU delegate, на Tensor G3 чипе Pixel 8 Pro — около 20 токенов/секунду.

Ограничения реальны: модели больше 4B параметров на мобильных устройствах по-прежнему медленны. Для сложных задач рассуждения on-device LLM уступает GPT-4o в качестве. Гибридный подход — on-device для коротких задач и приватных данных, облако для сложных запросов — часто оптимален. Оценим ваш кейс и предложим баланс производительности и приватности — пишите.

Интеграция OpenAI API и других облачных моделей

Для сценариев, где cloud inference допустим, интеграция OpenAI, Anthropic или Google Gemini — это HTTP клиент + streaming SSE. В Swift удобно через AsyncThrowingStream для стриминговых ответов. В Kotlin — через Flow.

Критически важно: API-ключи никогда не хранятся в бандле приложения. Даже обфусцированный ключ извлекается из IPA за 10 минут через strings или frida. Правильная архитектура: мобильное приложение → собственный backend → OpenAI API. Backend контролирует rate limiting, логирует запросы, защищает ключ.

Что входит в работу (deliverables)

• Обученная и квантизированная модель под целевое устройство (документация по метрикам)
• SDK для интеграции (Swift/Kotlin/Flutter) с примерами вызова
• Тесты производительности на 3–5 реальных устройствах
• Инструкция по обновлению модели OTA
• Поддержка при прохождении модерации App Store / Google Play (проверка соответствия Guidelines 4.2, 5.1)
• 2 недели технической поддержки после релиза

Типичный пайплайн проекта

1. Анализ задачи — замеряем latency, privacy, size, поддерживаемые устройства.
2. Прототипирование модели — в Python, оценка accuracy на целевых данных.
3. Конвертация и квантизация — под CoreML/TFLite с валидацией.
4. Интеграция в приложение — модель оборачивается в сервисный слой (легко подменять CoreML → TFLite → облако).
5. Тестирование — на реальных девайсах, замер FPS, RAM, батареи.
6. Деплой — через TestFlight / Firebase App Distribution, мониторинг метрик.

Сроки: интеграция готовой CoreML/TFLite модели — 1–2 недели, разработка кастомной модели с мобильной оптимизацией — от 6 недель, on-device LLM чат с персонализацией — 4–8 недель.

Почему мы беремся за сложные кейсы?

10+ лет опыта в мобильной разработке, 50+ внедрённых AI/ML решений, гарантия совместимости с актуальными версиями iOS и Android. Все проекты проходят code review и нагрузочное тестирование. В стоимость уже входит подготовка документации для модерации и обучение вашей команды.

Свяжитесь с нами — мы поможем выбрать архитектуру и внедрить ML в ваше приложение под ключ. Закажите аудит существующего решения — бесплатно оценим потенциал экономии серверных затрат (в некоторых проектах экономия достигает $10k в месяц).