From Sensor Data to Maintenance Alerts: Predictive Mobile Apps
Predictive Maintenance (PM) in a mobile context is not just a dashboard with charts. It is a system that collects data from sensors (vibration, temperature, current), runs it through an ML model, and issues a failure prediction before equipment stops. The mobile app acts as the interface for field technicians: they receive an alert, open an equipment card, see the anomaly on a trend, and decide on component replacement. We have implemented such projects for the oil & gas and mining sectors—with over 5 years of experience and 15+ deployments, achieving prediction accuracy up to 95% and reducing unplanned downtime by 45%.
Why On-Device ML Is Critical for Industrial Sites
Remote sites—mines, oil platforms, pipelines—often have unstable internet connections or operate entirely offline. On-device inference on an iPhone delivers a 50 ms response vs 150 ms for cloud calls (Apple Core ML benchmarks). This allows technicians to receive alerts instantly, even without a network. Lightweight models (pruned LSTM, compressed Random Forest) are converted to CoreML or TFLite and updated when a connection becomes available. A hybrid approach—on-device for primary detection, server for verification—ensures both speed and accuracy.
Where It Gets Really Hard
Data collection from equipment
Sensors deliver data via different protocols: Modbus RTU/TCP, OPC-UA, MQTT, sometimes BLE. The mobile app rarely communicates directly with them—usually there is an edge server (Raspberry Pi, Siemens IoT2040) that collects data and pushes it to the cloud. The app's task is to subscribe to MQTT topics or poll a REST API and correctly handle gaps in telemetry (sensor went offline for 2 minutes—that's not an anomaly, it's a connection break).
On Android, subscribing to MQTT is best kept in a ForegroundService with a persistent notification—this is the only way to guarantee real-time data reception without the process being killed by aggressive battery savers on Xiaomi and Huawei devices. Using WorkManager for MQTT is a mistake: it does not guarantee intervals shorter than 15 minutes.
Visualization of time series
Displaying 10,000 points on a vibration chart is not a simple drawLine in a loop. On iOS, the Charts library (formerly danielgindi/Charts) does not handle more than 2,000 points without downsampling. Solution: LTTB (Largest-Triangle-Three-Buckets)—a downsampling algorithm that preserves the visual shape of the curve while reducing the number of points by 10–20 times. Implemented on the client side before rendering.
ML model: server or on-device?
For industrial systems, the model typically lives on the server—data volume and complexity (LSTM, Isolation Forest, XGBoost) favor server-side inference. But if the site has no internet (mine, remote field), an on-device option is needed. CoreML on iOS and TFLite on Android handle lightweight models (pruned LSTM, ONNX-converted Random Forest). The model updates when a network is present via background download.
Which ML Model to Choose: On-Device or Server?
Selection criteria: network availability, latency, and data volume. On-device inference on an iPhone gives 50 ms vs 150 ms for cloud calls (Apple Core ML benchmarks). Server models support more complex architectures (LSTM with attention) and update centrally. We often use a hybrid: on-device model for initial detection, server model for verification and retraining.
| Characteristic | On-device (CoreML/TFLite) | Server (FastAPI + Celery) |
|---|---|---|
| Response time | <50 ms | 150-300 ms |
| Model update | Via internet, monthly | Continuously, no delay |
| Model complexity | Light (pruned LSTM, RF) | Heavy (LSTM, XGBoost) |
| Network dependency | No | Yes |
On-device inference is 3x faster than server-side on weak internet—critical for field technicians.
How We Build It
A typical stack: mobile app (React Native or Flutter for cross-platform, Swift/Kotlin for native requirements) + MQTT client (Eclipse Paho or mqtt_client for Flutter) + Python backend (FastAPI + Celery for scheduled inference) + TimescaleDB for telemetry storage.
On the ML side: the anomaly model is trained on historical data of normal equipment operation. We most often use Isolation Forest for initial detection and LSTM Autoencoder for more accurate classification of anomaly types. Models are exported to ONNX for unified inference.
The alert threshold is configured per device, not globally—the same pump in different operating conditions gives a different baseline vibration level.
How to Implement Predictive Maintenance: Step-by-Step Plan
- Step 1: Engineering audit – analyze sensors, protocols, data volumes, offline requirements. Identify control points and critical equipment.
- Step 2: Integration prototype – connect to one real device, collect telemetry for 1–2 weeks (approx. 500 MB daily). Evaluate data quality and throughput.
- Step 3: Label historical data – collect normal and failure records for ML model training. Minimum 1000 hours of equipment operation.
- Step 4: Develop MVP – dashboard with real-time readings, manual threshold alerts. Iterative testing with technicians.
- Step 5: Deploy ML model – train on labeled data, validate with accuracy ≥85%, deploy (server or on-device). Auto-update model.
- Step 6: Final testing – load testing (1000+ sensors), verify alerts on real failures, train personnel.
What's Included
- Engineering audit: sensor analysis, protocols, data volumes, offline requirements.
- Integration prototype with real equipment (without this, timeline estimation is meaningless).
- Collection and labeling of historical data for ML model training.
- Mobile app development: dashboard, charts, alerts, push notifications (APNs/FCM).
- ML pipeline deployment (server or on-device).
- Testing on real equipment with technicians.
- Documentation, personnel training, source code and access handover.
- Optional: SLA for support, model updates, infrastructure monitoring.
Process
We start with an audit: which sensors, protocols, data volume, is offline mode required. Then an integration prototype with real equipment (without this, timeline estimation is meaningless). In parallel, we collect historical data for model training.
Development proceeds iteratively: first raw data display in the app, then charts, then threshold alerts, then ML-based alerts. Each stage is validated with technicians on the actual site.
Typical project costs for such a system range from $80,000 to $150,000 depending on complexity, with average annual savings of $100,000–$250,000 per site.
Timeline Estimates
MVP with one sensor type, dashboard and threshold alerts: 4–6 weeks. Full system with ML model, multiple equipment types, offline mode, and ERP integration: 3–5 months. Cost is calculated individually after analyzing infrastructure and prediction accuracy requirements.
Average savings from Predictive Maintenance implementation range from $7,000 to $28,000 per year per site. We guarantee prediction accuracy of at least 85% on validation data—confirmed with a test run.
Contact us: we will assess your project and propose the optimal turnkey solution. Order a preliminary audit of your equipment—we will identify the potential for Predictive Maintenance and prepare a commercial proposal.