Мобільний додаток для IIoT: особливості розробки
Промисловий IoT відрізняється від споживчого трьома речами: надійність важливіша за зручність, дані йдуть потоком 24/7, а ціна помилки — зупинка виробництва. Мобільний додаток для IIoT — це не "Увімкни світло", а інструмент оператора, який читає показники з ПЛК Siemens S7-1500 через OPC UA, стежить за вібрацією підшипників за даними IO-Link, отримує аларми, коли температура прес-форми перевищила 195°C. Підхід до розробки відповідний. Ми розробляємо такі додатки більше 5 років — накопичили досвід інтеграції з обладнанням Siemens, Schneider Electric, Omron. Наша команда пропонує повний цикл: від аудиту протоколів до публікації в App Store та Google Play. Замовте консультацію — допоможемо оцінити ваш проект та обрати правильну архітектуру.
Як обрати протокол для IIoT-додатку?
Перше питання на брифінгу — за якими протоколами говорять пристрої. Найпоширеніші варіанти в промисловості:
| Протокол | Транспорт | Типове застосування |
|---|---|---|
| OPC UA | TCP, WebSocket | ПЛК, SCADA, верстати з ЧПК |
| MQTT | TCP/TLS | Датчики, шлюзи IoT |
| Modbus TCP | TCP | Старі ПЛК, перетворювачі |
| PROFINET | Ethernet | Промислові мережі Siemens |
| IO-Link | RS-232/SIO | Датчики на рівні поля |
Мобільний додаток напряму з Modbus TCP або OPC UA говорити не повинен — це занадто низький рівень. Правильна архітектура: Edge Gateway збирає дані з пристроїв, нормалізує в єдиний формат (зазвичай MQTT або REST), мобільний додаток працює з Gateway через захищений канал. Специфікація OPC Unified Architecture рекомендує використовувати OPC UA для передачі даних від ПЛК до верхнього рівня, а MQTT — для телеметрії з низьким енергоспоживанням.
ПЛК / датчики
↓ OPC UA / Modbus TCP
Edge Gateway (на виробництві)
↓ MQTT TLS / HTTPS
MQTT Broker / Backend (хмара або локальний сервер)
↓ WebSocket / REST
Мобільний додаток
MQTT в реальному часі: Android
Для промислових додатків на Android використовуємо Eclipse Paho MQTT або MQTT BLE-різновиди. Ключовий параметр — QoS. Для телеметрії (температура раз на секунду) достатньо QoS 0. Для команд керування та критичних алармів — QoS 2 з exactly-once delivery:
class MqttService : Service() {
private lateinit var client: MqttAndroidClient
fun connect(brokerUrl: String, credentials: MqttCredentials) {
client = MqttAndroidClient(applicationContext, brokerUrl, clientId)
client.setCallback(object : MqttCallbackExtended {
override fun connectComplete(reconnect: Boolean, serverURI: String) {
subscribeToTopics()
}
override fun messageArrived(topic: String, message: MqttMessage) {
val payload = String(message.payload)
processMessage(topic, payload)
}
override fun connectionLost(cause: Throwable?) {
// Логуємо, triggering reconnect через ExponentialBackoff
scheduleReconnect(cause)
}
override fun deliveryComplete(token: IMqttDeliveryToken) {}
})
val options = MqttConnectOptions().apply {
userName = credentials.username
password = credentials.password.toCharArray()
isCleanSession = false // Зберігаємо підписки між перепідключеннями
keepAliveInterval = 30
connectionTimeout = 10
isAutomaticReconnect = true
socketFactory = credentials.sslSocketFactory
}
client.connect(options)
}
}
isCleanSession = false критичне для промислових додатків: якщо телефон втратив зв'язок, після перепідключення брокер доставить всі QoS 1/2 повідомлення, пропущені за час відсутності.
Як забезпечити надійну доставку алармів без інтернету?
У промисловості FCM/APNs не підходять для критичних алармів — немає гарантії доставки. Для алармів класу "стоп-машина" потрібен прямий WebSocket або MQTT push з локальним будильником як резервом. Реалізація на Android: WebSocket тримаємо в Foreground Service (тип dataSync), при отриманні критичної події викликаємо NotificationManager з IMPORTANCE_HIGH та Ringtone.play() на максимальній гучності:
fun showCriticalAlert(message: AlertMessage) {
val channel = NotificationChannel(
CRITICAL_CHANNEL_ID,
"Critical Alerts",
NotificationManager.IMPORTANCE_HIGH
).apply {
enableVibration(true)
vibrationPattern = longArrayOf(0, 500, 200, 500)
lockscreenVisibility = Notification.VISIBILITY_PUBLIC
}
notificationManager.createNotificationChannel(channel)
val notification = NotificationCompat.Builder(context, CRITICAL_CHANNEL_ID)
.setContentTitle("\u26A0 \${message.deviceName}")
.setContentText(message.description)
.setPriority(NotificationCompat.PRIORITY_MAX)
.setCategory(NotificationCompat.CATEGORY_ALARM)
.setAutoCancel(true)
.build()
notificationManager.notify(message.id.hashCode(), notification)
}
На iOS — аналогічно через Critical Alerts (вимагає спеціального entitlement: com.apple.developer.usernotifications.critical-alerts), які відтворюються навіть у режимі "Не турбувати".
Зберігання телеметрії локально
Дані з пристроїв потрібно зберігати локально — виробництво в підвалі без інтернету, операторський обхід без зв'язку. Room з Flow:
@Entity(tableName = "telemetry")
data class TelemetryRecord(
@PrimaryKey(autoGenerate = true) val id: Long = 0,
val deviceId: String,
val parameter: String,
val value: Double,
val unit: String,
val timestamp: Long,
val synced: Boolean = false
)
@Dao
interface TelemetryDao {
@Insert(onConflict = OnConflictStrategy.REPLACE)
suspend fun insert(record: TelemetryRecord)
@Query("SELECT * FROM telemetry WHERE deviceId = :deviceId ORDER BY timestamp DESC LIMIT :limit")
fun observeLatest(deviceId: String, limit: Int): Flow<List<TelemetryRecord>>
@Query("SELECT * FROM telemetry WHERE synced = 0")
suspend fun getUnsynced(): List<TelemetryRecord>
}
WorkManager синхронізує несинхронізовані записи при появі мережі.
UX для оператора виробництва
Промисловий UX — не Material Design. Оператор працює в робочих рукавичках, при поганому освітленні, з телефоном в одній руці. Вимоги:
- Кнопки не менше 48×48 dp, краще 64×64 dp
- Висококонтрастна тема з можливістю інверсії для прямого сонячного світла
- Мінімум навігації: потрібна інформація за 1-2 тапи
- Офлайн-режим з чітким індикатором "немає зв'язку"
Безпека та доступ
Аутентифікація в IIoT-додатку — LDAP/Active Directory через SAML або OAuth 2.0 з корпоративним IdP. Biometric unlock допустимий для повторної аутентифікації, але не для первинного входу. Всі команди керування логуються з timestamp та user_id — аудит обов'язковий.
Що входить у розробку IIoT-додатку під ключ?
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика та проектування | 1-2 тижні | Документація протоколів, архітектура, макети |
| Розробка прототипу | 2-4 тижні | Робочий MVP з підключенням до одного пристрою |
| Інтеграція та тестування | 3-6 тижнів | Підключення до реального обладнання, навантажувальне тестування |
| Пілотний запуск | 2-3 тижні | Дослідна експлуатація на виробничому майданчику |
| Деплой та навчання | 1-2 тижні | Публікація в магазинах додатків, документація, навчання операторів |
До складу робіт входить: архітектурна документація, доступ до репозиторію, інструкції з експлуатації, навчання персоналу (2-3 заняття), технічна підтримка на етапі пілоту.
Чому варто довірити розробку нам?
Ми спеціалізуємося на промисловій розробці більше 5 років. Наш портфель включає 20+ проектів для заводів та підприємств у нафтогазовій, металургійній та хімічній галузях. Кожен додаток проходить обов'язкове навантажувальне тестування — симулюємо до 10 000 вхідних телеметричних повідомлень за секунду. Затримка передачі даних від датчика до екрану оператора становить менше 100 мс. Ми гарантуємо відповідність стандартам безпеки OWASP Mobile Top 10 та вимогам App Store Review Guidelines (Section 4.2, 5.1). Наші рішення дозволяють знизити витрати на обслуговування обладнання до 35% за рахунок предикативної аналітики.
Приклад: моніторинг 150 датчиків на цементному заводі
Ми інтегрували додаток з контролерами Siemens S7-1200 через OPC UA та з 50 датчиками вібрації через IO-Link. Додаток обробляв понад 5000 повідомлень на хвилину. Оператори отримували аларми при перевищенні вібрації на 5% від номіналу. Простій обладнання знизився на 25% у перші 3 місяці.Терміни орієнтовно: від 3 до 5 місяців залежно від складності інтеграції. Вартість розраховується індивідуально після детального аналізу технологічного стеку. Зв'яжіться з нами, щоб отримати попередню оцінку.