Реализация мониторинга состояния автомобиля через мобильное приложение

Реализация мониторинга состояния автомобиля через мобильное приложение

OBD-II порт есть в любом автомобиле, выпущенном после 1996 года. Через него ELM327-совместимый адаптер (Viecar, KONNWEI, Veepeak) по Bluetooth или Wi-Fi отдаёт PID-запросы — и приложение получает обороты двигателя, нагрузку, температуру охлаждающей жидкости, скорость, напряжение бортовой сети, коды ошибок DTC. Задача звучит просто, но реализация упирается в несколько нетривиальных моментов.

Протокол 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 парсить ответы значительно сложнее — команда возвращается в потоке вместе с ответом.

PID-опрос: что реально читается

Стандарт SAE J1979 определяет Mode 01 (текущие данные) и Mode 03 (коды ошибок). Не все PID поддерживаются всеми автомобилями — сначала запрашиваем PID 0x00 (supported PIDs 01-20), затем 0x20, 0x40, 0x60, чтобы построить карту доступных параметров.

Коды ошибок (Mode 03) возвращают список DTC в формате 2 байта на код. Первые два бита определяют систему: 00 — двигатель (P), 01 — трансмиссия (P1xxx), 10 — шасси (C), 11 — кузов (B). Декодирование кодов в читаемые описания требует базы данных — открытые варианты: CSV из репозитория hfreire/ecu-can-bus-decoder или платная база от OBD Solutions.

Архитектура приложения

На Android — foreground service с PRIORITY_LOW уведомлением (иначе Android 8+ убьёт процесс через несколько минут). Service управляет подключением к адаптеру и циклом опроса, UI подписывается через StateFlow. На iOS — foreground-only, поскольку Core Bluetooth работает в фоне только для Heart Rate и некоторых других профилей; опрос идёт пока экран активен.

Частота опроса: RPM и скорость — каждые 100-200 мс, температура и расход — каждые 1-2 секунды. Не опрашивайте все PID с одинаковой частотой — это перегружает адаптер и заметно замедляет шину CAN.

Дополнительно: 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 недель. Стоимость рассчитывается индивидуально после уточнения целевых платформ и списка поддерживаемых параметров.