Ошибка can шины elm327

Смеркалось. Решил я наконец-то заказать елм327, как все нормальные автолюбители. Пошел на самизнаететкакую интернет-площадку, выбрал вроде бы нормальный вариант, закупил. По описанию, как и советовали, версия 1.5, заказов много, отзывы положительные, кнопочка какая-то есть, опять же. Да, собственно, вот — ru.aliexpress.com/item/Mi…=a2g0s.9042311.0.0.Zt2p8P
Как пришел суперсканер, начал его синхронизировать по-всякому, с разными там торками и прочими идентифиерами. Как оказалось, сканер не совсем 1,5

Да, не 1,5. Да, не чипе PIC18F25K80. Но работает нормально, даже температуру ойлы в АКПП показывает. А что еще надо? Воткнул в разъем и катался, время от времени наблюдая за температурой ОЖ, которая не поднималась выше 80гр, сигнализируя о том, что новый термостат на 92гр закуплен в зиму совсем не зря и еще послужит не только в деле снижения температуры XER’а, но и в ее увеличении до приемлемых значений. В общем, в отсутствии БК игрался, как умел.
И вот, одним солнечным ноябрьским днем, поехал я с обеда на работу. Завожу, а мотор вдруг как заорет, лампы как заморгают, зуммер как запилинькает! Обороты дикие, горят все лампы, включая «открыта дверь», стрелка тахометра не шевелится, одометр показывает прочерки. Скоренько заглушил, сижу думаю, чего делать. Включаю зажигание, горит джекичан и абс, прочерки на одометре. Хм. Вытащил сканер из разъема, после этого включаю зажигание, джекичан на месте, но циферки на одометре появились, завожу — все нормально! Мысленно перекрестился и подключил сканер обратно… ничего не взорвалось, сканер считал ошибки:

U0073 — отключена коммуникационная шина А в модуле управления
P0700 — проблемы с системой контроля трансмиссии

Начал гуглить, как добрался до компьютера. Гугл как только не пугал, что только не предполагал, но среди прочих полезных советов на вроде выкинуть коробку, ЭБУ, заменить все разъемы и проводку, выдал интересный материал товарища Vovan059 — www.drive2.ru/l/8149619/, www.drive2.ru/l/8164895/
Собсно, подтвердив версию вины сканера. Да, ребята, не все сканеры одинаково полезны, особенно, если их держать постоянно включенными в диагностическом разъеме. В результате сканер пошел в бардачок, напоследок удалив ошибки. Что с ним не так, не знаю, скорее всего проблема в элементной базе, раз уж на чипе сэкономили, то уж и на всем остальном тоже.
Возможно эта заметка сбережет нервы тем, кто столкнется с подобной ситуацией в будущем. Ну а я заказал расово верный сканер полноценной версии 1,5, на рукопожатном PIC18F25K80, буду продолжать, не наигрался же еще.

---

---

---

---

---

---

---

---

---

---

Еще один ELM327 адаптер в коллекцию. Меня он заинтересовал крайне противоречивыми отзывами при использовании моего SZ Viewer. Некоторые радовались и говорили, что это хороший адаптер. У других были странные проблемы.

И вот этот адаптер у меня:

С виду обычный адаптер, у меня есть в похожем корпусе. Тоже с индикаторами и кнопкой. Но на этом фирменное название: NEXPEAK NX101.

На первый взгляд это обычный китайский ELM327 v1.5, что само по себе неплохо.

Если проверять на моем Suzuki Jimny, то все хорошо. Работает, достаточно стабильно, подключается ко всем модулям. Но у меня они только по K-Line отвечают.

А вот если проверить на машине с CAN-шиной, то все гораздо хуже. К модулям, работающими по CAN-шине, моя программа через этот адаптер подключается, но данные принять не может — выдается ошибка ответа.

Проблема оказалась в работе CAN Flow Control — это управление потоком нескольких CAN-сообщений, представляющих один целостный ответ. Об этом я уже рассказывал как раз на примере одной заложенной ошибки ELM327.

Что же в данном случае?

Опять тот же пример с запросом VIN стандартным OBD2 запросом 0902 (к сузуки не имеет отношения, но хорошо показывает проблему).

Если делать с настройками по умолчанию (т.е. в CAN Flow Control Mode 0), то все работает:

Но если, как я уже показывал, использовать CAN Flow Control Mode 1, то приходит только первое сообщение ответа:

Просмотр данных показывает, что в NX101 ошибочная реализация команды ATFCSD (установка сообщения для Flow Control). Она работает, влияет на запросы, но выставляет не то сообщение. Например, ATFCSD300000 выставляет не 30 00 00 00 00 00 00 00 как можно было ожидать, а 00 00 00 80 00 00 00 00.

Естественно, выставленное NX101 сообщение не является корректным, поэтому модуль управления так и не отправляет остаток сообщений.

Отсюда следует вывод: адаптер NEXPEAK NX101 почти нормальный v1.5 китайский адаптер, но с ошибкой в реализации ATFCSD.

Для текущей реализации SZ Viewer это означает, что работать с CAN-модулями автомобилей через этот адаптер невозможно. С K-Line модулями работа возможна без проблем.

К покупке этот адаптер не рекомендую.

Теперь вопрос концептуальный. Стоит ли поддерживать такие заведомо неисправные (с ошибками) адаптеры в SZ Viewer?

В принципе, я вижу два варианта, которые это позволят для этого адаптера.

1. Просто использовать CAN Flow Control Mode 0. Это работает (проверил), пусть и немного нестабильно в некоторых ситуациях (вызывает перезапросы)

Но из-за достаточно ограниченной реализации ELM327 возможно подключение через CAN только к модулям управления двигателем и AT/CVT. К остальным модулям через этот режим по CAN-шине подключиться невозможно.

2. Использовать все же CAN Flow Control Mode 1, но сделать специальную обработку именно этой ошибки NX101. По факту там перепутан порядок битов, экспериментальным образом подобрал, что для установки сообщения 30 00 00 00 00 00 00 00 надо вызывать команду ATFCSD00000006.

Это позволяет подключаться ко всем модулям по CAN-шине, но это именно самый настоящий «костыль» сугубо для данного адаптера.

Пока я еще не решил. Возможно, что более правильно подводить пользователей к использованию нормальных адаптеров, а не поддерживать продажи такого почти нормального, но все же неполноценного хлама.

p.s. А еще оцените на данном примере с какими изощренно-кривыми адаптерами приходится иметь дело. А потом злобные юзеры ругаются: «SZ Viewer глючит! А другие программы работают! Дизлайк-отписка».

Время на прочтение
7 мин

Количество просмотров 104K

Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.

По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.

Программный сниффер VCDS

Чтобы узнать по какому протоколу общаются электронные блоки я использовал специальную версию VCDS с программным сниффером в комплекте. В этот раз никаких железных снифферов на Arduino или RPi не пришлось изобретать. С помощью CAN-Sniffer можно подсмотреть общение между VCDS и автомобилем, чтобы затем телефон мог прикинуться диагностической утилитой и отправлять те же самые запросы.

Я собрал некоторую статистику по использованию диагностических протоколов на разных моделях автомобилей:

• VW/Skoda/Seat (2006-2012) — приборная панель UDS. Двигатель и трансмиссия VW TP 2.0

• Audi (2006-2012) — приборная панель VW TP 2.0. Двигатель UDS. Трансмиссия VW TP 2.0

• VW/Skoda/Seat/Audi (2012-2021) — везде UDS

Протокол UDS

Unified Diagnostic Services (UDS) — это диагностический протокол, используемый в электронных блоках управления (ЭБУ) автомобильной электроники. Протокол описан в стандарте ISO 14229-1 и является производным от стандарта ISO 14230-3 (KWP2000) и ныне устаревшего стандарта ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN)). Более подробно в википедии.

В моей машине (Skoda Octavia A5) приборка использует UDS протокол, это дало мне легкий старт разработки, т.к. данные были в простом формате Single Frame SF (фрейм, вся информация которого умещается в один CAN пакет) и большинство значений легко поддавались расшифровке. Volkswagen не дает документацию на формат значений, поэтому формулу расшифровки для каждого датчика приходилось подбирать методом логического мышления. Про UDS протокол очень хорошо и с подробным разбором фреймов написано на canhacker.ru.

Пример запроса и ответа температуры моторного масла:

7E0 0x03 0x22 0x11 0xBD 0x55 0x55 0x55 0x55
7E8 0x05 0x62 0x11 0xBD 0x0B 0x74 0x55 0x55

Запрос температуры моторного масла:

• 7E0 — Адрес назначения (ЭБУ двигателя)

• Байт 0 (0x03) — Размер данных (3 байта)

• Байт 1 (0x22) — SID идентификатор сервиса (запрос текущих параметров)

• Байт 2, 3 (0x11 0xBD) — PID идентификатор параметра (температура моторного масла)

• Байт 4, 5, 6, 7 (0x55) — Заполнитель до 8 байт

Ответ температуры моторного масла:

• 7E8 — Адрес источника (Диагностический прибор)

• Байт 0 (0x05) — Размер данных (5 байт)

• Байт 1 (0x62) — Положительный ответ, такой SID существует. 0x22 + 0x40 = 0x62. (0x7F) — отрицательный ответ

• Байт 2, 3 (0x11 0xBD) — PID идентификатор параметра (температура моторного масла)

• Байт 4, 5 (0x0B 0x74) — значение температуры моторного масла (20.1 °C формулу пока что не смог подобрать)

• Байт 6, 7 (0x55) — Заполнитель до 8 байт

Первая версия мобильного приложения VAG Virtual Cockpit умела подключаться только к приборной панели по UDS.

VW Transport Protocol 2.0

Volkswagen Transport Protocol 2.0 используется в качестве транспортного уровня, а данные передаются в формате KWP2000. Keyword Protocol 2000 — это протокол для бортовой диагностики автомобиля стандартизированный как ISO 14230. Прикладной уровень описан в стандарте ISO 14230-3. Более подробно в википедии.

Т.к. KWP2000 использует сообщения переменной длины, а CAN шина позволяет передавать сообщения не больше 8 байт, то VW TP 2.0 разбивает длинное сообщение KWP2000 на части при отправке по CAN шине и собирает заново при получении.

ЭБУ двигателя моей машины использует протокол VW TP 2.0, поэтому мне пришлось изучить его. Видимо Volkswagen разрабатывала транспортный протокол не только для работы по надежной CAN шине, но и для менее надежных линий связи, иначе нет объяснения для чего требуется такая избыточная проверка целостности данных. Главным источником информации по VW TP 2.0 является сайт https://jazdw.net/tp20.

Разбор протокола VW TP 2.0 на примере подключения к первой группе двигателя:

Во второй версии мобильного приложения VAG Virtual Cockpit появилась возможность диагностировать двигатель и трансмиссию по протоколу VW TP 2.0.

Диагностический адаптер ELM327

Для меня некоторое время было вопросом, как получить данные из CAN шины и передать на телефон. Можно было бы разработать собственный шлюз с Wi-Fi или Bluetooth, как это делают производители сигнализаций, например Starline. Но изучив документацию на популярный автомобильный сканер ELM327 понял, что его можно настроить с помощью AT команд на доступ к CAN шине.

Не все ELM327 одинаково полезны

Оригинальный ELM327 от компании elmelectronics стоит порядка 50$, в России я таких не встречал в продаже. У нас продаются только китайские копии/подделки, разного качества и цены 10-30$. Бывают полноценные копии, которые поддерживают все протоколы, а бывают и те которые умеют отвечать только на несколько команд, остальные игнорируют, такие адаптеры не имеют доступ к CAN шине. Я например пользуюсь копией Viecar BLE 4.0, который поддерживает 100% всех функций оригинала.

Для работы с протоколом UDS через ELM327 нужно указать адреса назначения, источника и разрешить длинные 8 байтные сообщения, по умолчанию пропускается максимум 7 байт.

Последовательность ELM327 AT команд для работы с UDS по CAN шине:

ATZ // сброс настроек
AT E0 // отключаем эхо
AT L0 // отключаем перенос строки
AT SP 6 // Задаем протокол ISO 15765-4 CAN (11 bit ID, 500 kbaud)
AT ST 10 // Таймаут 10 * 4 мс, иначе EBU шлет повторные ответы каждые 100 мс, а мы не отвечаем, потому что ожидаем конца, а нам нужен только первый ответ
AT CA F0
AT AL // Allow Long (>7 byte) messages
AT SH 7E0 // задаем ID, к кому обращаемся (двигатель)
AT CRA 7E8 // CAN Receive Address. Можно задать несколько 7Xe
AT FC SH 7E0
AT FC SD 30 00 00
AT FC SM 1 // Режим Flow Control 1 должен быть определен после FC SH и FC SD, иначе в ответ придет "?"
03 22 F4 0С 55 55 55 55 // UDS запрос оборотов двигателя

Для работы с протоколом KWP2000 через ELM327 нужно только указать адреса назначения и источника.

Последовательность ELM327 AT команд для работы с VW TP 2.0 по CAN шине:

ATZ // сброс настроек
AT E0 // отключаем эхо
AT L0 // отключаем перенос строки
AT SP 6 // Задаем протокол ISO 15765-4 CAN (11 bit ID, 500 kbaud)
AT PB C0 01
AT SP B // Задаем протокол USER1 CAN (11* bit ID, 125* kbaud)
AT ST 10 // Таймаут 10 * 4 мс, иначе EBU шлет повторные ответы каждые 100 мс, а мы не отвечаем, потому что ожидаем конца, а нам нужен только первый ответ
AT SH 200 // Обращаемся к 200 ID
AT CRA 201 // Ждем ответа от 201 Блок управления двигателем, 202 - Transmission, 203 - ABS, 207 -  Приборная панель
01 C0 00 10 00 03 01 // Initiate channel setup with ECU module - 01, request it use CAN ID 0x300; Transmission 02; ABS 03
AT SH 740 // адрес блока 740 получен в ответе на предыдущую команду
AT CRA 300 // Ждем ответа от 300 ID
A0 0F 8A FF 32 FF // Tell ECU module to send 16 packets at a time, and set timing parameters
10 00 02 10 89 // Send KWP2000 startDiagnosticSession request 0x10 with 0x89 as a parameter.
B1 // ACK
11 00 02 1A 9B // Запрос названия блока KWP2000

Мобильное приложение VAG Virtual Cockpit

Для разработки мобильного приложения подключаемого к автомобилю требовалось:

• Сниффером собрать трафик от диагностической утилиты VCDS

• Изучить работу протоколов UDS, VW TP 2.0, KWP2000

• Настроить диагностический сканер ELM327 на работу с UDS и VW TP 2.0

• Изучить новый для меня язык программирования Swift

В итоге получилось приложение, которое сочетает в себе функции отображения точных данных панели приборов и диагностика основных параметров двигателя и трансмиссии.

Пару слов про точность данных. Штатная панель приборов не точно показывает скорость — завышает показания на 5-10 км/ч, стрелка охлаждающей жидкости всегда на 90 °C, хотя реальная температура может быть 80 — 110 °C, стрелка уровня топлива до середины идет медленно, хотя топлива уже меньше половины и при нуле на самом деле топливо еще есть в баке. Производитель это делает для удобства и безопасности водителя.

На данный момент приложение показывает следующие параметры:

Я стремлюсь чтобы приложение поддерживало как можно больше моделей автомобилей. Пока что поддерживаются производители: Volkswagen, Skoda, Seat, Audi. На разных комплектациях могут отображаться не все параметры, но это поправимо.

Сейчас я провожу тестирование версии 3.0. Приложение доступно только на iOS, после релиза 3.0 перейду к разработке версии для Android.

Если интересно потестировать и есть желание принять участие в проекте, то установить приложение можно по ссылке. Также я веду бортжурнал на drive2.ru, где делюсь полезной информацией и новостями о VAG Virtual Cockpit.