AI-предиктивне обслуговування IoT-пристроїв у мобільному додатку

Обертове обладнання — насоси, компресори, двигуни — часто виходить з ладу раптово через приховані дефекти підшипників, дисбаланс або деградацію ізоляції. Позаплановий простій на промисловому об'єкті коштує десятки тисяч гривень на годину, а аварійний ремонт вимагає екстреної логістики запчастин і простою суміжних агрегатів. Середня вартість позапланового ремонту відцентрового насоса становить 150 000–300 000 грн, а кожна година простою технологічної лінії обходиться в 1,5 млн грн. На одному з наших об'єктів аварійна зупинка компресора призвела до втрати 4,2 млн грн за 3 години. Ці цифри мотивують впроваджувати предиктивну аналітику вже на етапі проектування системи обслуговування.

Ми розробляємо мобільні рішення для предиктивного обслуговування IoT-пристроїв, які дозволяють замовникам скоротити ці простої за рахунок раннього виявлення дефектів. З нашим досвідом (понад 5 років в IoT-аналітиці) та гарантією якості ви отримуєте систему, реально працюючу на промислових об'єктах. Замовте передпроектне дослідження, щоб оцінити потенціал економії на вашому обладнанні.

Які моделі прогнозування використовуються

Класичний підхід для обертового обладнання включає аналіз наступних сигналів:

• RMS вібрації з акселерометра — зростання вказує на дисбаланс або знос підшипника.
• Спектр FFT — характерні частоти дефектів підшипників (BPFI, BPFO, BSF, FTF за геометрією підшипника).
• Температура обмоток — тренд зростання при деградації ізоляції.
• Струм двигуна (MCSA) — зміна гармонік при механічних дефектах.

Для детекції аномалій використовуються Isolation Forest або LSTM Autoencoder на часових рядах, для класифікації типу дефекту — XGBoost або LightGBM, для оцінки залишкового ресурсу (RUL) — Survival Analysis (Weibull regression). Навчання виконується на серверній стороні (Python, scikit-learn, PyTorch). У мобільний додаток модель вивантажується через REST API або в скомпільованому форматі для локального інференсу. Для діагностики насосів AI-моделі показують найкращі результати при використанні комбінації XGBoost та LSTM енкодера.

Як організувати локальний інференс на Android та iOS

Для нестабільного зв'язку (промислові об'єкти) модель виконується на пристрої.

Покрокова інструкція з розгортання TFLite моделі

1. Експорт моделі з Python у формат TFLite з квантуванням у FP16.
2. Додайте файл .tflite до директорії assets Android-додатку.
3. Ініціалізуйте Interpreter з увімкненням NNAPI делегата для GPU-прискорення.
4. Використовуйте метод run() з вхідним тензором з нормалізованих ознак.

Нижче — приклад на Android з TFLite.

class RULPredictor(context: Context) {
    private val interpreter: Interpreter
    init {
        val model = loadModelFromAssets(context, "rul_model.tflite")
        val options = Interpreter.Options().apply {
            addDelegate(NnApiDelegate())
            setNumThreads(2)
        }
        interpreter = Interpreter(model, options)
    }
    fun predictRUL(sensorFeatures: FloatArray): PredictionResult {
        val inputBuffer = ByteBuffer.allocateDirect(4 * sensorFeatures.size)
            .order(ByteOrder.nativeOrder())
        sensorFeatures.forEach { inputBuffer.putFloat(it) }
        val outputBuffer = Array(1) { FloatArray(2) }
        interpreter.run(inputBuffer, outputBuffer)
        return PredictionResult(
            rulDays = outputBuffer[0][0].toInt(),
            confidence = outputBuffer[0][1]
        )
    }
}

Feature engineering перед інференсом: з сирих часових рядів розраховуються статистики (mean, std, RMS, peak, crest factor, kurtosis, skewness) за ковзним вікном. На iOS використовується Core ML з .mlpackage, конвертація з scikit-learn через coremltools.convert(). Порівняння моделей за точністю та продуктивністю:

Що відображати на екрані пристрою

Головний екран — список обладнання з кольоровими індикаторами здоров'я. При тапі відкривається картка, де видно:

• Health Score (0-100) — агрегований показник стану.
• RUL — прогноз залишкового ресурсу в днях/годинах з довірчим інтервалом.
• Активні аномалії з описом («Аномально висока вібрація по осі X, характерно для дисбалансу ротора»).
• Тренди ключових параметрів за 7/30/90 днів.
• Історія обслуговування.

Push-сповіщення при різкому погіршенні: «Насос ЦН-2, будівля 5: вібрація зросла на 40% за 24 години. RUL знижено до 12 днів». Пріоритетний пуш через FCM PRIORITY_HIGH для обходу Doze Mode.

Як інтегрувати з CMMS

При досягненні порогу RUL автоматично створюється заявка на техобслуговування в CMMS (SAP PM, IBM Maximo, Infor EAM). Механік через мобільний додаток приймає Work Order, сканує QR обладнання, фіксує виконані роботи та запчастини, закриває з підписом. Після обслуговування скидаються лічильники напрацювання та оновлюється baseline моделі.

Деталі процесу: як ми навчаємо моделі

Для клієнта з нафтогазової галузі ми навчили LSTM Autoencoder на даних вібрації з 20 насосів за 6 місяців. Після валідації модель показала 94% точності прогнозу відмови за 7 днів. На етапі аналітики ми збираємо історичні дані з датчиків, проводимо очищення та feature engineering. Вибір ML-моделі здійснюється за метрикою MAPE та F1. Після навчання модель валідується на відкладеній вибірці. Потім ми пакуємо модель у TFLite/Core ML та вбудовуємо в додаток. Останній етап – налаштування push-сповіщень через FCM та інтеграція з CMMS через REST API.

Що входить в роботу

• Архітектура та інтеграція з IoT-платформою.
• Вибір та навчання ML-моделей під ваші дані.
• Розробка мобільного додатку (iOS/Android).
• Налаштування push-сповіщень та CMMS-інтеграція.
• Тестування та деплой з гарантією якості.

Замовте пілотний проект – ми навчимо модель на ваших даних і покажемо результат за 2 тижні.

Строки та вартість

Розробка AI-компонента предиктивного обслуговування поверх існуючого IoT-додатку — від 6 до 10 тижнів. Повний цикл (ML-моделі + мобільний додаток + CMMS-інтеграція) — від 4 до 6 місяців. Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Орієнтовна економія від впровадження досягає 30–50% витрат на позаплановий ремонт.

Чому локальний інференс важливий для IoT?

Локальний інференс вирішує ключові проблеми промислових об'єктів: нестабільний зв'язок, високі вимоги до затримок та конфіденційність даних. Модель на пристрої видає прогноз за мілісекунди, не залежить від хмари та не передає сирі дані назовні.

Як порівняти моделі за точністю?

Використовуйте метрику MAPE (Mean Absolute Percentage Error) для RUL та F1-score для класифікації дефектів. На практиці XGBoost дає найкращий баланс точності та розміру моделі, але LSTM Autoencoder краще виявляє складні аномалії. Вибір залежить від типу обладнання та доступних обчислювальних ресурсів.

Типові дефекти та їх індикатори

Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію з впровадження AI-моделей предиктивного обслуговування.

Детальніше про методи предиктивного обслуговування читайте в Wikipedia — Predictive maintenance.

Інтеграція з залізом: BLE, NFC, IoT та HomeKit у мобільних додатках

Коли задача — зв’язати смартфон з фізичним пристроєм, половина проблем знаходиться не в коді, а в прошивці заліза, характеристиках BLE-сервісів та затримках протоколу. Ми, як мобільні розробники, працюємо на стику з firmware-командою, і без розуміння стеку знизу вгору результат непередбачуваний. Ось чому ми завжди починаємо з HCI-логу та специфікації GATT — Apple Developer: Core Bluetooth Framework — це єдиний спосіб уникнути реверс-інжинірингу в польових умовах.

Чому BLE-інтеграція — найчастіша точка відмови?

Bluetooth Low Energy — основний протокол для носимих, медичних пристроїв, розумних замків та промислових датчиків. Core Bluetooth на iOS та BluetoothGatt на Android реалізують одну специфікацію, але поводяться по-різному в крайніх випадках. Статистика наших проектів: більше 70% звернень у підтримку по BLE пов’язані саме з низькорівневими помилками GATT, а не з логікою додатку.

Що робити з помилкою 133 в Android?

Помилка 133 — найчастіша в Android BLE-розробці. Це не «щось пішло не так», а конкретний індикатор переповнення черги GATT або некоректного закриття попереднього з’єднання. Ми лікуємо її двома прийомами: використовуємо чергу операцій над GATT (write, read, notification subscribe строго послідовно через операційну чергу) та завжди викликаємо disconnect() перед close(). Наша черга GATT-операцій у 3 рази знижує кількість помилок ATT_INSUFFICIENT_RESOURCES порівняно з конкурентними запитами. MTU за замовчуванням — 23 байти. Запит на збільшення (MTU exchange) обов’язковий для передачі даних об’ємом понад 20 байт. На iOS MTU запитується автоматично при підключенні, на Android потрібно явно викликати requestMtu(). Без цього ви не зможете передати, наприклад, зображення або лог через характеристику.

NFC: CoreNFC та Android NFC API

iOS підтримує NFC-читання через CoreNFC з версії iOS 11, запис — з iOS 13. Важливе обмеження: сесія сканування активна лише поки живий об’єкт NFCNDEFReaderSession і показує системний UI. Фонове сканування доступне лише для додатків з entitlement com.apple.developer.nfc.readersession.formats і лише для ISO 14443 (банківські картки, паспорти) — і цей entitlement видається не всім. На Android все простіше: NfcAdapter.enableForegroundDispatch() ловить теги у foreground без системного UI. Фоновий запуск додатку по NFC-тегу реалізується через intent-filter з ACTION_NDEF_DISCOVERED. Порівняння платформ по NFC:

HomeKit та Matter

HomeKit — екосистема Apple для розумного дому. Для інтеграції пристрій повинен мати MFi-сертифікацію (або працювати через Software Authentication для Matter). Мобільний додаток використовує HomeKit framework: HMHomeManager → HMHome → HMRoom → HMAccessory → HMService → HMCharacteristic. Matter (раніше CHIP) — крос-платформний стандарт, який підтримують Apple, Google, Amazon та Samsung. На iOS Matter-пристрої додаються через MTRDeviceController, на Android — через Google Home SDK або Matter SDK безпосередньо. Перевага Matter: один пристрій працює з HomeKit, Google Home та Alexa без перепрошивки, а конфігурація налаштовується в 4 рази швидше порівняно з власним HAP-протоколом.

Для Flutter та React Native використовуємо flutter_blue_plus та react-native-ble-plx відповідно — обидва активно підтримуються і покривають 90% сценаріїв, але для роботи з GATT-нотифікаціями у background на Android все одно потрібен foreground service. Переконайтеся, що deep linking (Universal Links на iOS, App Links на Android) налаштовані для коректного пробудження додатку при скануванні NFC-тегу або отриманні push-повідомлення від IoT-пристрою. Вимоги ATT (App Tracking Transparency) для інтеграції з залізом зазвичай не застосовуються, але якщо додаток збирає анонімну аналітику — додайте запит. Отримайте консультацію нашого інженера — він розбере вашу специфікацію за 2 дні.

Як ми інтегруємо BLE та NFC?

1. Аналітика — отримуємо від firmware-команди повну специфікацію BLE GATT (список сервісів, характеристик, формати даних) або HCI-лог. Без цього розробка перетворюється на реверс-інжиніринг через nRF Connect або Wireshark over HCI.
2. Проектування — визначаємо архітектуру підключень: чергу GATT-операцій, фонові сервіси для Android, перепідключення при втраті зв’язку. Враховуємо MTU-узгодження та обробку помилок ATT_INSUFFICIENT_RESOURCES.
3. Реалізація — кодимо на Swift/Kotlin з урахуванням особливостей платформ (Universal Links, App Links, push-повідомлення через APNs/FCM для тригерів). Для захисту Android-коду використовуємо ProGuard / R8 (shrink).
4. Тестування — на реальних пристроях з першого дня. Емулятор BLE в симуляторах не відтворює edge cases перепідключення, втрати сигналу, зміни MTU. Використовуємо автоматизацію на базі XCTest та Espresso.
5. Деплой — завантаження в App Store Connect / Google Play Console з правильним code signing та provisioning profile. Для iOS — TestFlight, для Android — Firebase App Distribution.

Що входить в роботу (deliverables)

• Вихідний код мобільного додатку з інтеграцією BLE, NFC або IoT (Swift / Kotlin / Flutter / React Native)
• Документація по протоколу GATT (карта сервісів та характеристик)
• Навантажувальне тестування на 10+ реальних пристроях (помилка 133, перепідключення, MTU-узгодження)
• Аналіз та усунення edge cases (помилка ATT_INSUFFICIENT_RESOURCES, втрата з’єднання на фоні, конфлікт з background fetch)
• Інструкція зі збірки та деплою (code signing, TestFlight, Firebase App Distribution)
• Місяць підтримки після релізу

Строки та орієнтовна вартість

Проста інтеграція з одним BLE-периферійним пристроєм (показання + команди керування) — від 2 до 4 тижнів. Типова вартість такої задачі розраховується індивідуально, включаючи налагодження GATT-профілю та обробку edge cases. Повноцінний IoT-додаток з декількома типами пристроїв, firmware OTA-оновленнями та HomeKit-підтримкою — від 2 місяців. Вартість розраховується індивідуально під ваш проект.

Ми займаємося мобільною розробкою кілька років — досвід 45+ проектів з BLE/NFC/HomeKit. Наші інженери сертифіковані Apple та Google, а кожен етап роботи фіксується в issue tracker з прив’язкою до комітів. Ми гарантуємо прозорість процесу та дотримання строків. Використовуємо підхід «інженер клієнту»: без маркетингових пауз, з прямим доступом до розробника.

Закажіть оцінку — отримайте консультацію інженера з розбором вашої специфікації. Замовте інтеграцію під ключ: ми проаналізуємо HCI-лог, перевіримо GATT-характеристики та запропонуємо архітектуру за 2 дні.