Проблема: як отримати реальний стан автомобіля через OBD-II
Власники автопарків часто стикаються з ситуацією: машина на ходу, але витрата палива раптово зросла, або загорівся Check Engine, а до найближчого сервісу 500 км. Моніторинг через OBD-II дає повну картину, але реалізація додатку впирається в купу нюансів: протоколи адаптерів, фоновий опит під Android та iOS, декодування DTC. Ми вирішуємо ці задачі 5+ років і накопичили понад 50 проєктів.
OBD-II порт є в будь-якому автомобілі, випущеному з середини 1990-х. Через нього ELM327-сумісний адаптер (Viecar, KONNWEI, Veepeak) по Bluetooth або Wi-Fi віддає PID-запити — і додаток отримує оберти двигуна, навантаження, температуру охолоджувальної рідини, швидкість, напругу бортової мережі, коди помилок DTC. Задача звучить просто, але реалізація впирається в кілька нетривіальних моментів.
Які дані можна отримати через OBD-II?
Стандарт SAE J1979 визначає Mode 01 (поточні дані) та Mode 03 (коди помилок). Не всі PID підтримуються всіма автомобілями — спочатку запитуємо PID 0x00 (supported PIDs 01-20), потім 0x20, 0x40, 0x60, щоб побудувати карту доступних параметрів.
| PID | Параметр | Формула |
|---|---|---|
| 0x04 | Навантаження двигуна | A * 100 / 255 % |
| 0x05 | Температура охолоджувальної рідини | A - 40 °C |
| 0x0C | Оберти двигуна | (256*A + B) / 4 RPM |
| 0x0D | Швидкість | A км/год |
| 0x11 | Положення дросельної заслінки | A * 100 / 255 % |
| 0x42 | Напруга бортової мережі | (256*A + B) / 1000 В |
| 0x5E | Витрата палива | (256*A + B) / 20 л/год |
Коди помилок (Mode 03) повертають список DTC у форматі 2 байти на код. Перші два біти визначають систему: 00 — двигун (P), 01 — трансмісія (P1xxx), 10 — шасі (C), 11 — кузов (B). Декодування кодів у читабельні описи потребує бази даних — відкриті варіанти: CSV з репозиторію hfreire/ecu-can-bus-decoder або платна база від OBD Solutions.
Які помилки виникають при роботі з ELM327 і як їх уникнути?
Адаптери ELM327 говорять через AT-команди поверх послідовного порту. Підключення через Classic Bluetooth — BluetoothSocket на Android з UUID 00001101-0000-1000-8000-00805F9B34FB (SPP профіль). На iOS Classic Bluetooth для сторонніх додатків закритий; єдиний шлях — BLE ELM327 адаптери (Viecar EA400-P, OBDLink CX) через Core Bluetooth.
Найчастіша помилка при роботі з ELM327 — відправити наступний PID-запит, не дочекавшись > (prompt) у відповіді. Адаптер буферизує команди непередбачувано, і замість значення RPM додаток отримує ? або NO DATA. Правильний цикл опитування — послідовний, з таймаутом очікування промпту ~200 мс:
class OBDConnection(private val socket: BluetoothSocket) { private val input = socket.inputStream.bufferedReader() private val output = socket.outputStream suspend fun sendCommand(command: String): String = withContext(Dispatchers.IO) { output.write("$command\r".toByteArray()) val sb = StringBuilder() var char: Int while (input.read().also { char = it } != -1) { val c = char.toChar() sb.append(c) if (c == '>') break } sb.toString().trim().removeSuffix(">").trim() } suspend fun readPID(mode: String, pid: String): String { return sendCommand("$mode$pid") } } Ініціалізація адаптера перед опитуванням обов'язкова: ATZ (скидання), ATE0 (вимкнути луну), ATL0 (без переносу рядка), ATSP0 (автовибір протоколу). Без ATE0 парсити відповіді значно складніше — команда повертається в потоці разом з відповіддю.
Використання корутин з асинхронними таймаутами скорочує час повного циклу опитування вдвічі порівняно з блокуючими потоками, особливо при опитуванні 15+ PID.
Як відбувається процес розробки?
Ми підходимо до проєкту системно: спочатку аналізуємо вимоги та сумісність з автомобілями замовника, проєктуємо архітектуру, потім реалізуємо на Kotlin/Android або Swift/iOS. Після тестування на реальних адаптерах публікуємо додаток у сторах. Весь процес включає:
- Аналітика та складання карти PID для цільових авто
- Проєктування модулів: OBD-з'єднання, база даних, сповіщення
- Реалізація з використанням Jetpack Compose або SwiftUI
- Тестування на фізичних адаптерах (декілька моделей)
- Деплой у Google Play та App Store
Архітектура додатку
На Android — foreground service з низьким пріоритетом сповіщення (інакше Android 8+ вб'є процес через кілька хвилин). Service керує підключенням до адаптера та циклом опитування, UI підписується через StateFlow. На iOS — foreground-only, оскільки Core Bluetooth працює у фоні тільки для Heart Rate та деяких інших профілів; опитування йде поки екран активний.
| Параметр | Android | iOS |
|---|---|---|
| Підключення OBD-II | Classic Bluetooth (SPP) | BLE (тільки BLE-адаптери) |
| Фонове опитування | Foreground service | Тільки при активному екрані |
| Push-сповіщення | Firebase | APNs |
| Інструменти | Kotlin, Jetpack Compose | Swift, SwiftUI |
Частота опитування: RPM та швидкість — кожні 100-200 мс, температура та витрата — кожні 1-2 секунди. Не опитуйте всі PID з однаковою частотою — це перевантажує адаптер та помітно сповільнює шину CAN. Для push-сповіщень про наближення ТО використовуємо календар та одометр.
Що входить у нашу роботу
Ми здаємо проєкт під ключ: вихідний код додатку, документацію з архітектури та підключення, інструкції для користувача, а також допомагаємо з публікацією у сторах. Надаємо гарантію на виправлення помилок протягом 3 місяців після здачі.
Додатково: TPMS та камера салону
Датчики тиску шин (TPMS) на більшості автомобілів працюють через окремий радіочастотний протокол (315/433 МГц) і не доступні через OBD-II. Для їх моніторингу потрібні зовнішні BLE-датчики (наприклад, Meneea, Fobo Tire Plus), які кріпляться на вентиль і передають тиск та температуру. Інтегруються через стандартний Core Bluetooth / Android BLE API.
Орієнтири по термінах
Розробка базового мобільного додатку з підключенням до ELM327, моніторингом 10-15 PID та читанням DTC: 3-4 тижні. Повноцінний додаток з історією поїздок, геолокацією, розрахунком витрати палива та TPMS: 6-8 тижнів. Вартість розраховується індивідуально після уточнення цільових платформ та списку підтримуваних параметрів. Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати попередню оцінку.
Отримайте консультацію з моніторингу автопарку — ми допоможемо обрати оптимальний набір датчиків та адаптерів.