Уявіть: виробнича лінія, 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 місяців. Вартість розраховується індивідуально після аналізу ваших джерел даних. Типова економія від впровадження становить мільйони гривень на рік за рахунок зниження простоїв та витрат на позапланові зупинки. Замовте консультацію інженера з мобільної розробки.
