Уявіть: виробнича лінія, 500 датчиків вібрації, температури та тиску. Щосекунди — 250 000 семплів. Оператор не встигає стежити за всім. Потрібен мобільний застосунок, який покаже лише критичні відхилення. Ми розробляємо такі рішення — від збору даних з PLC до сповіщень на смартфоні. Зв'яжіться з нами для обговорення архітектури вашого IIoT-рішення. Наш досвід — понад 10 років у промисловому інтернеті речей (IIoT), понад 50 проєктів для заводів. Без правильної архітектури застосунок захлинеться в потоці даних. Тому на першому етапі ми проєктуємо систему збору та нормалізації даних на Edge-шлюзах, а потім будуємо надійний real-time канал передачі.
Мобільний моніторинг промислового обладнання: ключові технічні рішення
Edge-компонент — промисловий шлюз (Moxa, Advantech, Siemens IPC) або кастомний Linux-сервер — нормалізує дані з різних протоколів та публікує агрегати в MQTT або віддає через REST/WebSocket. Для мобільного застосунку важливі два потоки: реальний час — поточні значення ключових параметрів, оновлення раз на 1-5 секунд через WebSocket; та історія — тренди за зміну, добу, тиждень через REST API з пагінацією та агрегацією.
Як влаштований збір даних у реальному часі?
На рівні обладнання дані збирає Edge-компонент: промисловий шлюз (Moxa, Advantech, Siemens IPC) або кастомний Linux-сервер. Він нормалізує дані з різних протоколів (OPC-UA, Modbus, MQTT) та публікує агрегати в MQTT або віддає через REST/WebSocket.
Датчики → PLC / Edge Gateway → Time-Series DB (InfluxDB / TimescaleDB) ↓ Backend API (REST + WebSocket) ↓ Мобільний застосунок Агрегація та нормалізація на Edge-шлюзі — мобільний моніторинг промислового
Згідно з документацією OPC-UA Part 6, шлюз перетворює адресний простір OPC-UA на плоскі теги. Для Modbus — мапінг регістрів на фізичні величини (наприклад, регістр 40001 = температура з коефіцієнтом 0.1). Агрегація: середнє, мінімум, максимум за вікно 1 секунда. Це знижує трафік у 10-100 разів.
| Протокол | Застосування | Частота опитування | Складність інтеграції |
|---|---|---|---|
| OPC-UA | PLC, CNC | 1-1000 мс | Середня |
| Modbus RTU/TCP | Датчики, контролери | 10-1000 мс | Низька |
| MQTT | IoT-пристрої | 1-60 с | Низька |
| Siemens S7 | SIMATIC S7 | 10-100 мс | Висока |
Чому архітектура збору даних — головний виклик?
Використовуємо Flutter з WebSocket. Для надійності — автоматичне перепідключення з експоненційною затримкою.
class EquipmentMonitorRepository { WebSocketChannel? _channel; final StreamController<EquipmentState> _stateController = StreamController.broadcast(); Stream<EquipmentState> get stateStream => _stateController.stream; void connect(String equipmentId, String token) { _channel = WebSocketChannel.connect( Uri.parse('wss://iiot.factory.com/ws/equipment/$equipmentId'), ); _channel!.stream .map((event) => json.decode(event as String)) .map(EquipmentState.fromJson) .listen( _stateController.add, onError: _handleError, onDone: _scheduleReconnect, ); _channel!.sink.add(json.encode({'auth': token})); } void _scheduleReconnect() { Future.delayed(const Duration(seconds: 5), () => connect(_lastId, _lastToken)); } } Приклад реалізації BLoC для керування станом
class EquipmentMonitorBloc extends Bloc<EquipmentEvent, EquipmentMonitorState> { StreamSubscription<EquipmentState>? _subscription; EquipmentMonitorBloc(this._repository) : super(EquipmentMonitorInitial()) { on<StartMonitoring>((event, emit) async { _subscription = _repository.stateStream.listen( (state) => add(StateUpdated(state)), ); _repository.connect(event.equipmentId, event.token); }); on<StateUpdated>((event, emit) { final current = event.state; final isAlert = current.temperature > 85.0 || current.vibrationRms > 12.5; emit(EquipmentMonitorRunning(state: current, hasAlert: isAlert)); }); } } WebSocket у 20 разів швидший за HTTP polling при передачі телеметрії. Порівняйте:
| Спосіб | Затримка | Навантаження на батарею | Навантаження на сервер |
|---|---|---|---|
| HTTP polling | >1 сек | Висока | Висока |
| WebSocket | <100 мс | Низька | Низька |
| gRPC-stream | <50 мс | Середня | Середня |
Візуалізація трендів та відхилень
Для історичних даних використовуємо fl_chart (Flutter) або MPAndroidChart. Ключова оптимізація — агрегація на стороні API. Запит до InfluxDB-based API:
GET /api/v1/equipment/{id}/trend? parameter=temperature& from=2023-01-15T06:00:00Z& to=2023-01-15T18:00:00Z& resolution=300 # агрегація по 5 хвилин Відповідь — масив із 144 точок замість 43 200. Чарт малює без фризів.
Baseline та відхилення
Корисна функція — відображення baseline (нормального діапазону) на графіку. Якщо струм двигуна в нормі 12-15А, виділяємо зону, і оператор одразу бачить відхилення:
LineChartData buildTrendChart(List<TrendPoint> data, Range baseline) { return LineChartData( extraLinesData: ExtraLinesData( horizontalLines: [ HorizontalLine(y: baseline.min, color: Colors.green.withOpacity(0.3)), HorizontalLine(y: baseline.max, color: Colors.green.withOpacity(0.3)), ], ), betweenBarsData: [ BetweenBarsData( fromIndex: 0, toIndex: 0, color: Colors.green.withOpacity(0.1), ), ], lineBarsData: [ LineChartBarData( spots: data.map((p) => FlSpot(p.timestamp.toDouble(), p.value)).toList(), color: data.any((p) => p.value > baseline.max || p.value < baseline.min) ? Colors.red : Colors.blue, ), ], ); } Що потрібно врахувати при розробці?
- Агрегація даних — не передавати сирі семпли, лише агрегати.
- Офлайн-режим — кешувати останні показники та алерти в локальній БД.
- Ескалація алертів — якщо оператор не прийняв алерт за 5 хвилин, сповістити майстра.
- Безпека — TLS, JWT, шифрування на пристрої.
- Тестування — симуляція до 10 000 пристроїв.
Для зниження трафіку на Edge-шлюзі застосовується ковзне вікно: з 25 600 семплів з вібродатчика формується 1-10 агрегатів — середнє, пік, RMS, частота основного тону.
Етапи розробки
- Аудит джерел даних — розбір протоколів та частоти опитування.
- Проектування архітектури — вибір Edge-компонента та Time-Series DB.
- Розробка бекенду — API агрегації, WebSocket, алерти.
- Розробка мобільного застосунку — UI, тренди, push-сповіщення.
- Інтеграція та тестування — на реальному обладнанні.
- Деплой та підтримка — App Store / Google Play, моніторинг.
Що входить у результат?
- Вихідний код мобільного застосунку (iOS/Android/Flutter).
- Бекенд-сервіс з API та WebSocket.
- Документація з інтеграції та розгортання.
- Доступ до репозиторію та CI/CD.
- Навчання операторів (до 2 годин).
- Гарантія 6 місяців на баги.
Вартість та терміни
Розробка застосунку для одного типу обладнання з WebSocket та трендами — від 4 до 8 тижнів. Повний цикл з офлайн-режимом та ескалацією — від 2 до 4 місяців. Вартість розраховується індивідуально після аналізу ваших джерел даних. Типова економія від впровадження становить мільйони гривень на рік за рахунок зниження простоїв та витрат на позапланові зупинки. Замовте безкоштовну консультацію інженера з мобільної розробки.