Подключение к can шине через obd2
Для работы с CAN шиной автомобиля необходимо знать:
CAN шина – это сеть обмена данными определенная в стандарте ISO 11898. Другие каналы обмена данными в автомобиле не могут быть названы CAN шиной. AVC-LAN, BEAN, J1708, VAN и другие старые протоколы это НЕ CAN !
В автомобиле может быть более одной CAN шины. Для каждого функционального сегмента автомобиля выделяется своя сеть CAN. Выделенные сети могут работать на разных скоростях.
Скорости работы CAN шины
CAN на разных автомобилях и в разных сегментах сети может работать на разных скоростях.
Названия сегментов сети: Мотор, Шасси, Комфорт, Салон – условны! У Каждого автопроизводителя свои названия этих участков сети!
- Группа VAG: Мотор\шасси – 500 кбит\с, Комфорт – 100 кбит\с и с 2018 года шина Комфорт может иметь скорость 500 кбит\с., Диагностика: 500 кбит\с.
- BMW : Мотор\Шасси – 500кбит\с, Комфорт – 100 кбит\с и с 2018 года шина Комфорт может иметь скорость 500 кбит\с., Диагностика: 500 кбит\с.
- Mercedes-Benz : Мотор\Шасси – 500 кбит\с, Комфорт 83.333 кбит\с, 250 кбит\с, Диагностика: 500 кбит\с.
- Ford, Mazda : Мотор\Шасси – 500 кбит\с, Комфорт 125 кбит\с. (Для Ford может быть больше вариантов)
- KIA\Hyundai : Мотор\Шасси – 500 кбит\с, Комфорт 125 кбит\с, 500 кбит\с, Мультимедиа: 125 кбит\с, 500 кбит\с., Диагностика: 500 кбит\с.
- GM : Мотор\Шасси – 500 кбит\с, Комфорт: 33.333 кбит\с, 95.2 кбит\с, Диагностика: 500 кбит\с.
- Toyota, Nissan, Honda, Subaru, Suzuki : 500 кбит\с (может использоваться гейтвей)
- Mitsubishi : Мотор\Шасси: 500 кбит\с, Салон\Комфорт – 83.333 кбит\с, 250 кбит\с, Диагностика: 500 кбит\с.
- Volvo : Мотор\Шасси: 500 кбит\с, Салон\Комфорт – 500 кбит\с, 125 кбит\с, Диагностика: 500 кбит\с.
- Renault : 500 кбит\с
- Peugeot : Мотор\Шасси – 500 кбит\с, Комфорт 125 кбит\с.
- Lada : 500 кбит\с
- Коммерческая и специальная техника : Стандарт J1939 250 или 500 кбит\с.
Сегментация CAN шины по функциональному назначению
- Как правило разные, сегменты сети разделены специальным устройством, которое называется Гейтвей (Gateway, ZGW, ETACS, ICU) .
- В роли гейтвея может выступать панель приборов (для простых автомобилей) или отдельный специальный модуль межсетевого интерфейса.
- Гейтвей разделяет потоки данных в разных сегментах сети и обеспечивает связь сегментов сети работающих на разных скоростях.
- ВАЖНО: На многих автомобилях (особенно VAG, MB, BMW) CAN шина в диагностическом разъеме OBD2 отделена от других участков сети при помощи гейтвея, поэтому подключившись к CAN шине OBD разъема невозможно увидеть поток данных. В этом случае можно увидеть только обмен между диагностическим инструментом и автомобилем во время процесса диагностики! Так же модулем гейтвеем оборудованы автомобили японских марок с 2016..2018 годов в зависимости от модели.
- ОБЯЗАТЕЛЬНО изучайте схемы на исследуемый автомобиль, чтобы знать к какому сегменту сети Вы подключаетесь!
Схема ниже изображена в общем виде для упрощения понимания роли Гейтвея. Количество CAN шин и варианты включения блоков управления к тому или другому сегменту сети могут отличаться.
Реализации CAN на уровне электрических сигналов
CAN шина может быть реализована физически тремя способами:
Классическая витая пара нагруженная с обоих концов резисторами 120 Ом.
В этом случае уровни на шине CAN выглядят так:
Для такой реализации сети используются как правило обычные CAN трансиверы в 8 выводном корпусе, аналоги PCA82C250, TJA1050 и им подобные. Работает такая конфигурация на скоростях 500 кбит\с и выше. (Но могут быть исключения) .
В этом варианте используется та же витая пара, но линии CAN-Low и CAN-High подтянуты к напряжению питания и массе соответственно.
Подробное описание FT-CAN по ссылке
Такой вариант CAN шины способен переключаться в однопроводный режим в случае повреждения одной из линий. Работает на скоростях до 250 кбит\с.Уровни сигнала на шине отличаются от High Speed CAN, при этом не теряется возможность работы с шиной FT-CAN используя трансиверы High-Speed CAN и соблюдая ряд условий.
Подробнее в нашей статье о FT-CAN – ссылка.
Fault tolerant CAN обычно используется для низкоскоростного обмена между блоками управления относящимися к сегменту сети Салон\Комфорт\Мультимедиа.
ВАЖНО: При подключении к шине Faul tolerant CAN, подключать терминальный резистор 120 Ом между линиями CAN-High и CAN-Low НЕ НУЖНО !
3 Single Wire CAN или SW-CAN
Однопроводный вариант шины CAN. Работает на скорости 33.333 кбит\с
Используется специальный тип трансиверов. Для того что бы подключиться к такому варианту шины CAN необходимо линию CAN-High анализатора подключить к шине SW-CAN а линию CAN-Low к массе\земле.
В этой статье я расскажу как собрать свою уникальную виртуальную или цифровую панель приборов и получить данные с любых датчиков в автомобилях группы VAG (Volkswagen, Audi, Seat, Skoda).
Мною был собран новый CAN сниффер и CAN шилд для Raspberry Pi на базе модуля MCP2515 TJA1050 Niren, полученные с их помощью данные я применил в разработке цифровой панели приборов с использованием 7″ дисплея для Raspberry Pi. Помимо простого отображения информации цифровая панель реагирует на кнопки подрулевого переключателя и другие события в машине.
В качестве фреймворка для рисования приборов отлично подошел Kivy для Python. Работает без Иксов и для вывода графики использует GL.
- CAN сниффер из Arduino Uno
- Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)
- Разработка панели приборов на основе Raspberry Pi и 7″ дисплея
- Софт панели приборов на Python и Kivy (UI framework)
- Видео работы цифровой панели приборов на базе Raspberry Pi
CAN сниффер из Arduino Uno
Чтобы послушать, что отправляет VCDS в CAN шину я собрал сниффер на макетке из Arduino и модуля MCP2515 TJA1050 Niren.
Схема подключения следующая:
CanHackerV2 позволяет смотреть пролетающий трафик, записывать и проигрывать команды с заданным интервалом, что очень сильно помогает в анализе данных.
Подслушиваем запросы с помощью диагностической системы VAG-COM (VCDS)
Программно-аппаратный сканер VCDS предназначен для диагностики электронных систем управления, устанавливаемых на автомобилях группы VAG. Доступ ко всем системам: двигатель, ACP, АБС, климат-контроль, кузовая электроника и т.п., считывание и стирание кодов неисправностей, вывод текущих параметров, активация, базовые установки, адаптация, кодирование и т.п.
Подключив сниффер к линиям CAN_L и CAN_H в диагностическом шнурке я смог увидеть какие запросы делает VCDS и что отвечает авто.
Особенность авто группы VAG в том, что OBD2 разъем подключен к CAN шине через шлюз и шлюз не пропускает весь гуляющий по сети трафик, т.е. подключившись в OBD2 разъем сниффером вы ничего не увидите. Чтобы получить данные в OBD2 разъёме нужно отправлять шлюзу специальные запросы. Эти запросы и ответы видно при прослушивании трафика от VCDS. Например вот так можно получить пробег.
В VCDS можно получить информацию почти с любого датчика в машине. Меня в первую очередь интересовала информация, которой вообще нет на моей приборке, это:
- температура масла
- какая именно дверь открыта
Разработка панели приборов на основе Raspberry Pi и 7″ дисплея
В качестве аппаратной части я выбрал Raspberry Pi. Была идея использовать Android планшет, но показалось, что на Raspberry Pi будет проще и быстрее. В итоге докупил официальный 7″ дисплей, и сделал CAN шилд из модуля TJA1050 Niren.
OBD2 штекер использовал от старого ELM327 адаптера.
Используются контакты: CAN_L, CAN_H, +12, GND.
Тесты в машине прошли успешно и теперь нужно было все собрать. Плату дисплея, Raspberry Pi и блок питания разместил на куске черного пластика, очень удачно подобрал пластмассовые втулки, с ними ничего не болтается и надежно закреплено.
Местом установки выбрал бардачок на торпедо, которым я не пользуюсь. По примеркам в него как раз помещается весь бутерброд.
Напильником довел лист черного пластика до размера крышки бардачка, к нему прикрепил бутерброд и дисплей. Для прототипа сойдет, а 3D модель с крышкой для дисплея и всеми нужными крепежами уже в разработке.
Софт панели приборов на Python и Kivy (UI framework)
Параллельно со сборкой самой панели приборов я вел разработку приложения для отображения информации с датчиков. В самом начале я не планировал какой либо дизайн.
Первая версия панели приборов
По мере разработки решил визуализировать данные более наглядно. Хотел гоночный дизайн, а получилось, что-то в стиле 80-х.
Вторая версия панели приборов
Продолжив поиски более современного дизайна я обратил внимание какие цифровые приборки делают автопроизводители и постарался сделать что-то похожее.
Третья версия панели приборов
Ранее, я никогда не разрабатывал графические приложения под Linux поэтому не знал с чего начать. Вариант на вебе простой в разработке, но слишком много лишних компонентов: иксы, браузер, nodejs, хотелось быстрой загрузки. Попробовав Qt PySide2 я понял, что это займет у меня много времени, т.к. мало опыта. Остановился на Kivy — графический фреймворк для Python, простой в понимании с полной библиотекой графических элементов и дающий возможность быстро создать мобильный интерфейс.
Kivy позволяет запускать приложение без Иксов, прямо из консоли, в качестве рендера используется OpenGL. Благодаря этому полная загрузка системы может происходить за 10 секунд.
Алгоритм работы следующий, используется 3 потока:
- В главном потоке работаем с графическими элементы (спидометр, тахометр, часы, температуры и др) на экране
- Во втором потоке каждые 5 мс делаем опрос следующего датчика
- В третьем потоке слушаем CAN шину, получив ответ парсим его и обновляем соответствующий графический элемент
Проект цифровой панель приборов открытый. Рад буду предложениям и комментариям!
Мобильное приложение VAG Virtual Cockpit
Я продолжаю изучать CAN шину авто. В предыдущих статьях я голосом открывал окна в машине и собирал виртуальную панель приборов на RPi. Теперь я разрабатываю мобильное приложение VAG Virtual Cockpit, которое должно полностью заменить приборную панель любой модели VW/Audi/Skoda/Seat. Работает оно так: телефон подключается к ELM327 адаптеру по Wi-Fi или Bluetooth и отправляет диагностические запросы в CAN шину, в ответ получает информацию о датчиках.
По ходу разработки мобильного приложения пришлось узнать, что разные электронные блоки управления (двигателя, трансмиссии, приборной панели и др.) подключенные к CAN шине могут использовать разные протоколы для диагностики, а именно UDS и KWP2000 в обертке из VW Transport Protocol 2.0.
Программный сниффер VCDS
Программный сниффер VCDS: CAN-Sniffer
Чтобы узнать по какому протоколу общаются электронные блоки я использовал специальную версию 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)). Более подробно в википедии.
Диагностические данные от двигателя по протоколу UDS (Skoda Octavia A7)
Разбор UDS пакета в формате Single Frame
Пример запроса и ответа температуры моторного масла:
Запрос температуры моторного масла:
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.
VAG Virtual Cockpit - экран с данными от приборной панели по протоколу UDS
VW Transport Protocol 2.0
Volkswagen Transport Protocol 2.0 используется в качестве транспортного уровня, а данные передаются в формате KWP2000. Keyword Protocol 2000 - это протокол для бортовой диагностики автомобиля стандартизированный как ISO 14230. Прикладной уровень описан в стандарте ISO 14230-3. Более подробно в википедии.
Диагностические данные от двигателя по протоколу KWP2000 (Skoda Octavia A5)
Разбор протокола VW TP 2.0 на примере подключения к первой группе двигателя:
200 01 C0 00 10 00 03 01
Настраиваем канал с двигателем. Байт 0: 0x01 - двигатель, 0x02 - трансмиссия. Байт 5,4: 0x300 - адрес источника
201 00 D0 00 03 40 07 01
Получили положительный ответ. Байт 5,4: 0x740 - к двигателю обращаемся по этому адресу
740 A0 0F 8A FF 32 FF
Настраиваем ЭБУ на отправку сразу 16 пакетов и выставляем временные параметры
300 A1 0F 8A FF 4A FF
Получили положительный ответ
740 10 00 02 10 89
Отправляем команду KWP2000 startDiagnosticSession. Байт 0: 0x10 = 0b0001 - последняя строка данных + 0x0 счетчик отправляемых пакетов 0 (0x0 - 0xF)
Получили первый ACK
300 10 00 02 50 89
Получили положительный ответ. Байт 0: 0x10 - cчетчик принимаемых пакетов 0
Мы отправили первый ACK, что получили ответ
740 11 00 02 21 01
Делаем запрос. Байт 0: 0x11 - счетчик отправляемых пакетов 1. Байт 3: 0x21 - запрос параметров. Байт 4: 0x01 - из группы 1
Получили второй ACK
300 22 00 1A 61 01 01 C8 13
Байт 0: 0x22 - 0b0010 (не последняя строка данных) + 0x02 (cчетчик принимаемых пакетов 2). Байт 1,2: 0x00 0x1A длина 26 байт. Байт 3,4: 0x61 0x01 - положительный ответ на команду запроса параметров 0x21+0x40=0x61 из 0x1 группы. Байт 5: 0х01 - Запрос RPM (соответсвует протоколу KW1281). Байт 6,7: (0xC8 * 0x13)/5 = 760 RPM (формула соответствует протоколу KW1281)
300 23 05 0A 99 14 32 86 10
Байт 1: 0x05 - запрос ОЖ. Байт 2,3: (0x0A * 0x99)/26 = 57.0 C. Байт 4: 0x14 = запрос лямбда контроль %. Байт 5,6: 0x32*0x86; Байт 7: 0х10 - двоичная настройка
300 24 FF BE 25 00 00 25 00
0x25 0x00 x00 - Заполнитель, до 8 параметров
300 15 00 25 00 00 25 00 00
Байт 0: 0x15 - 0b0001 (последняя строка данных) + 0x5 (счетчик принимаемых пакетов 5)
Отправляем ACK. Прибывляем к нашему предыдущему ACK количество полученных пакетов 0xB1 + 0x4 = 0xB5
Запрос KeepAlive, что мы еще на связи
740 A1 0F 8A FF 4A FF
Мы разрываем связь
ЭБУ в ответ тоже разрывает связь
Во второй версии мобильного приложения VAG Virtual Cockpit появилась возможность диагностировать двигатель и трансмиссию по протоколу VW TP 2.0.
VAG Virtual Cockpit - экран с данными от двигателя по протоколу VW TP 2.0
Диагностический адаптер ELM327
Для меня некоторое время было вопросом, как получить данные из CAN шины и передать на телефон. Можно было бы разработать собственный шлюз с Wi-Fi или Bluetooth, как это делают производители сигнализаций, например Starline. Но изучив документацию на популярный автомобильный сканер ELM327 понял, что его можно настроить с помощью AT команд на доступ к CAN шине.
Копия диагностического сканера ELM327 Не все ELM327 одинаково полезны
Оригинальный ELM327 от компании elmelectronics стоит порядка 50$, в России я таких не встречал в продаже. У нас продаются только китайские копии/подделки, разного качества и цены 10-30$. Бывают полноценные копии, которые поддерживают все протоколы, а бывают и те которые умеют отвечать только на несколько команд, остальные игнорируют, такие адаптеры не имеют доступ к CAN шине. Я например пользуюсь копией Viecar BLE 4.0, который поддерживает 100% всех функций оригинала.
Последовательность ELM327 AT команд для работы с UDS по CAN шине:
Для работы с протоколом KWP2000 через ELM327 нужно только указать адреса назначения и источника.
Последовательность ELM327 AT команд для работы с VW TP 2.0 по CAN шине:
Мобильное приложение VAG Virtual Cockpit
Для разработки мобильного приложения подключаемого к автомобилю требовалось:
Сниффером собрать трафик от диагностической утилиты VCDS
Изучить работу протоколов UDS, VW TP 2.0, KWP2000
Настроить диагностический сканер ELM327 на работу с UDS и VW TP 2.0
Изучить новый для меня язык программирования Swift
В итоге получилось приложение, которое сочетает в себе функции отображения точных данных панели приборов и диагностика основных параметров двигателя и трансмиссии.
Пару слов про точность данных. Штатная панель приборов не точно показывает скорость - завышает показания на 5-10 км/ч, стрелка охлаждающей жидкости всегда на 90 °C, хотя реальная температура может быть 80 - 110 °C, стрелка уровня топлива до середины идет медленно, хотя топлива уже меньше половины и при нуле на самом деле топливо еще есть в баке. Производитель это делает для удобства и безопасности водителя.
На данный момент приложение показывает следующие параметры:
Приборная панель
Двигатель
Трансмиссия (температура)
1) Какая дверь открыта
2) Скорость
3) Обороты
4) Температура масла
5) Температура ОЖ
6) Топливо в баке в л.
7) Запас хода в км.
8) Средний расход
9) Время в машине
10) Пробег
11) Температура за бортом
1) Обороты
2) Массовый расход воздуха
3) Температура забора воздуха
4) Температура выхлопа (рассчитанная)
5) Критический уровень масла
6) Уровень масла
7) Наддув турбины (реальный)
8) Наддув турбины (ожидаемый)
9) Пропуски зажигания в цилиндрах
10) Углы откатов зажигания в цилиндрах
1) ATF AISIN (G93)
2) DSG6 (G93)
3) Блок управления DSG6 (G510)
4) Масло диска сцепления DSG6 (G509)
5) Мехатроник DSG7 (G510)
6) Процессор DSG7
7) Диск сцепления DSG7
Я стремлюсь чтобы приложение поддерживало как можно больше моделей автомобилей. Пока что поддерживаются производители: Volkswagen, Skoda, Seat, Audi. На разных комплектациях могут отображаться не все параметры, но это поправимо.
Сейчас я провожу тестирование версии 3.0. Приложение доступно только на iOS, после релиза 3.0 перейду к разработке версии для Android.
Выбор подключения
Изначально необходимо пояснить что для подключения к авто будет использоваться ELM327 адаптер. ELM327 – это микросхема, которая позволяет преобразовать протоколы, используемые в диагностических шинах автомобилей в протокол RS232, которым мы и будем передавать данные. За счет того что передача данных по протоколу RS232 происходит последовательно возникает первая проблема – скорости передачи данных, которую мы постараемся обойти в одном из следующих пунктов.
Существует несколько вариаций адаптера ELM327, которые классифицируются по способу передачи данных – Bluetooth, WIFI, USB. Исходя из того что целью разработки является мобильное устройство под операционной системой Android можно подобрать две наиболее подходящие версии ELM327, такие как Bluetooth и WIFI. Так как способ получения и обработки данных один, а отличаются они всего лишь вариантами подключения к адаптеру, то можно выбрать всего один, организовать при помощи него диалог, а после добавить остальные варианты подключения.
ELM327 1.5 vs ELM327 2.1
Одной из первых проблем, с которыми можно столкнуться стала проблема выбора непосредственно адаптера, в нашем случае Bluetooth. Оказывается если вам необходимо поддерживать все (по крайней мере большинство) автомобилей необходимо выбирать версию v1.5 вместо v2.1, что на самом то деле необходимо несколько раз уточнить при покупке адаптера, потому как продавцы пытаются выдать версию адаптера не за ту, которая есть на самом деле, т.к. они особо ничем не отличаются. На деле же в версии v2.1 отсутствует поддержка протоколов J1850 PWM и J1850 VPW, что говорит о том, что у вас не получится подключиться к автомобилям, которые используют эти протоколы.
Подключение
Подключение к адаптеру происходит в несколько этапов:
- Подключение к адаптеру (Bluetooth, WIFI)
- Отправка инициализационных команд (инициализационной строки)
AT Z [reset all]
Сброс настроек адаптера до заводского состояния.
AT L1-0
Включить/Отключить символы перевода строки.
AT E1-0
Echo on – off
AT H1-0
Headers on – off
AT AT0-1-2
Adaptive Timing Off — adaptive Timing Auto1 — adaptive Timing Auto2
AT ST FF
Установить таймаут на максимум.
AT D [set all to Default]
Сброс настроек в исходное, настроенное пользователем состояние.
AT DP [Describe the current Protocol]
Сканер способен самостоятельно определять протокол автомобиля, к которому он подключен.
AT IB10 [set the ISO Baud rate to 10400]
Команда устанавливает скорость обмена данных для ISO 9141-2 и
ISO 14230-4 10400
AT IB96 [ set the ISO Baud rate to 9600]
Команда устанавливает скорость обмена данных для ISO 9141-2 и
ISO 14230-4 9600 для протоколов 3,4,5.
AT SP h [ Set Protocol h]
Команда выбора протокола h, где h:
0 – Automatic;
1 — SAE J1850 PWM (41.6 Kbaud);
2 — SAE J1850 VPW (10.4 Kbaud);
3 — ISO 9141-2 (5 baud init, 10.4 Kbaud);
4 — ISO 14230-4 KWP (5 baud init, 10.4 Kbaud);
5 — ISO 14230-4 KWP (fast init, 10.4 Kbaud);
6 — ISO 15765-4 CAN (11 bit ID, 500 Kbaud);
7 — ISO 15765-4 CAN (29 bit ID, 500 Kbaud);
8 — ISO 15765-4 CAN (11 bit ID, 250 Kbaud);
9 — ISO 15765-4 CAN (29 bit ID, 250 Kbaud);
AT SP Ah [Set Protocol h with Auto]
Команда устанавливает по умолчанию протокол h, если подключение по протоколу h не удалось, тогда адаптер начинает автоматический подбор протокола.
Исходя из описанных выше команд, формируем инициализационную строку.
Так же желательно обратить внимание на команду APSP0, таким образом мы устанавливаем по умолчанию автоматический подбор протокола, это может занять некоторое время.
Соответственно если пользователь знает какой у его авто протокол, то используя возможность смены протокола подключения он может поменять 0 на номер его протокола.
Считывание диагностических данных
Для считывания диагностических данных используются специальные команды PID’s.
PID (Parameter id’s — Бортовые диагностические идентификаторы параметров) – коды, которые используются для запроса показателей определенных датчиков автомобиля.
Основные пиды можно найти в Википедии, там полный набор основных команд, которые должны поддерживать все автомобили. Так же есть наборы команд для определенных марок и типов автомобилей, эти наборы предоставляются за отдельную плату. В нашем случае приложение заточено на базовую диагностику автомобилей соответственно мы используем базовый набор команд.
Также есть возможность получать текущие данные от автомобиля при этом команда получения данных от авто будет иметь вначале 01, указывая на то что мы хотим получить real data. Если же мы хотим получить сохраненные данные автомобиля, то вначале команды необходимо указать 02. Например, команда для получения текущей скорости автомобиля – 010D, а для получения сохраненной скорости – 020D.
Если внимательно посмотреть на то количество команд, которое предоставляется открытыми ресурсами, то можно как раз и заметить ту проблему, о которой я писал в самом начале, а именно проблема скорости ответа адаптера. Так как отправка и получение команд идет последовательно, то для того чтобы получить показания датчика на текущий момент времени необходимо дождаться ответа на все предыдущие команды. Соответственно если запрашивать на получение все команды, то большая вероятность того что обновление реальных данных будет происходить очень медленно. Но и эту проблему можно решить, если воспользоваться командами, которые отобразят только те команды, что существуют в автомобиле. Например:
0100 – PIDs supported [01 — 20]
0120 – PIDs supported [21 — 40]
0140 – PIDs supported [41 — 60]
0160 – PIDs supported [61 — 80]
0180 – PIDs supported [81 – A0]
01A0 – PIDs supported [A1 — C0]
Я продемонстрирую как определить какие датчики присутствуют в автомобиле при помощи одного из пидов. Например:
- 0100 \\ запрос
- BB1E3211 \\ ответ от авто
Используя следующую табличку можем определить какие пиды поддерживаются нашим автомобилем, начиная от 01 до 20:
Исходя из получившихся данных можем определить, что наш автомобиль поддерживает следующие пиды:
Теперь вместо отправки всех 32 команд и ожидания ответа на них, несмотря на то, что некоторые могут отсутствовать, мы будем использовать всего 15 команд. Но и это не предел так называемой оптимизации. Для того чтобы данные обновлялись еще быстрее советую запрашивать только данные о тех датчиках, которые отображаются на экране. Хотя это ограничивает некоторый функционал приложения. Например, запись истории.
Считывание и расшифровка ошибок автомобиля
Ошибки автомобиля тоже могут быть различными и для них тоже существуют отдельные команды. Например:
- 03 – Для отображения сохраненных кодов ошибок
- 0A – Для отображения постоянных кодов ошибок.
А теперь пояснение.
3, 4, 5 символы формируются по этой таблице:
Исходя из этого можем попробовать разобрать следующий ответ 0001000000111110
Код ошибки: P103E
Эпилог
На данном этапе мы разобрались в том, каким образом организовать диалог с адаптером, посылать ему команды, получать и расшифровывать его ответы. Это большая часть работы, если считать то, сколько времени уходит на изучение материала, но в то же время довольно таки интересная. За пределами этой статьи осталось множество проблем связанных с визуальным интерфейсом, а также множество дополнительных функций, таких как добавление новых пидов из файла, стандартный и расширенный способ подключения к адаптеру и построения графиков.
Матвиенко Александр, Хоссейн Фахр.
P.S. Оригинальную английскую версию статьи можно найти здесь
Пожалуйста, прочитайте этот материал полностью!
Установка драйвера
После установки драйвера и подключения интерфейса к компьютеру в диспетчере устройств в разделе Порты должно появиться устройство “STM Virtual Com Port”. Порту будет присвоен номер, например COM3, как на скриншоте ниже. Номер порта будет необходимо ввести в программе CARBUS Analyzer при подключении к интерфейсу, поэтому запомните этот номер.
Возможные проблемы при установки драйвера и методы их решения
Проблемы при установке драйвера могут возникать на старых версиях Windows XP и Windows 7. При этом в диспетчере интерфейс определяется как виртуальный COM порт, но при попытке соединиться с ним, программное обеспечение зависает, либо выдает ошибку. В этом случае обратите внимание на, что на нашем сайте доступны для загрузки два варианта драйверов, и необходимо попробовать установить версию драйвера отличную от той, которая была установлена в первую очередь. Как правило это помогает решить проблему.
Вторая проблема может заключаться в низкой скорости работы интерфейса. В этом случае принимаемые пакеты отображаются с явной задержкой. Это может является следствием того, что на компьютере устаревший контроллер USB. Решить проблему поможет использование внешнего USB хаба (разветвителя), который согласует размер пакетов интерфейса и USB контроллера материнской платы компьютера.
Для работы с интерфейсом CAN-Hacker 3.2 в качестве анализатора шин CAN и LIN необходимо скачать программное обеспечение CARBUS Analyzer на странице СКАЧАТЬ.
Затем распаковать скачанный архив.
В архиве находится как сама программа CARBUS Analyzer, так и утилита для обновления прошивок UBT (папка UBT) с папка с набором актуальных прошивок (UBT\Firmware files)
Настройка программы CARBUS Analyzer и интерфейса для работы с шиной CAN
Если Вы новичок в работе с шиной CAN, обязательно прочтите материал по ссылке.
В меню Settings, в выпадающем списке Device type выбрать CAN_Hacker v 3.x
В выпадающем списке Device mode необходимо выбрать режим работы интерфейса. Доступные режимы:
- CAN Dual channel + LIN – работа с шинами CAN и LIN одновременно (опция LIN должна быть активирована)
- CAN Dual channel – работа только с шиной CAN
- LIN Only – работа только с шиной LIN (опция LIN должна быть активирована)
В выпадающем списке Source необходимо выбрать порт, на котором определяется интерфейс в системе .
Настройка каналов CAN
Настройка каналов CAN осуществляется на вкладках Channel 1: CAN и Channel 2: CAN. Эти вкладки становятся видимой после выбора режима интерфейса для работы с шиной CAN.
Channel baudrate – задает скорость работы CAN шины.
Флаг Listen only mode – переводит интерфейс в режим Listen only, в котором теряется возможность отправки пакетов, но при приеме передаваемых по шине пакетов интерфейс не выставляет на шине флаг подтверждение приема ACK, что делает интерфейс невидимым для других устройств на шине.
Подключение к CAN шине
Подключение к CAN шине осуществляется при помощи поставляемого с интерфейсом кабеля
Назначение проводов:
Желтый с черной полосой – CAN-Low канал 1
Желтый с белой полосой– CAN-High канал 1
Оранжевый с черной полосой – CAN-Low канал 2
Оранжевый с белой полосой – CAN-High канал 2
Назначение переключателей на плате
DIP переключатель на плате устройства служит для подключения резисторов терминаторов 120 Ом между линиями CAN-High и CAN-Low. В положении ON резисторы подключены.
При подключении к однопроводным шинам CAN (SWCAN – Single wire CAN, GMLAN) необходимо провод CAN-Low подключить на массу (GND) исследуемого автомобиля или блока управления, а провод CAN-High на линию SWCAN\GMLAN.
Если настройки CAN произведены верно, физическое подключение к шине верно и на шине присутствует обмен данными то после нажатия кнопки Connect в окне приема отобразятся данные передаваемые по шине CAN.
Подробное описание работы с программой CARBUS Analyzer в качестве анализатора CAN шины Вы найдете на отдельной странице – ссылка.
Работа с шиной LIN
(Должен быть установлен и активирован LIN адаптер )
Для работы с шиной LIN необходимо перевести интерфейс CAN-Hacker 3.2 в режим работы анализатора шины LIN. Для этого необходимо:
- Зайти в меню Settings
- В выпадающем списке Device type выбрать CAN-Hacker v3.x
- В выпадающем списке Device mode выбрать CAN Dual channel + LIN или LIN Only
- В выпадающем списке Source выбрать порт на котором в системе определился интерфейс.
После выбора типа и режима интерфейса необходимо:
- Перейти на вкладку Channel 1: LIN. Которая активируется после выбора режима LIN на предыдущей вкладке Device.
- В выпадающем списке Channel baudrate выбрать скорость обмена на шине LIN
- В выпадающем списке Detection time выбрать минимальную предполагаемую паузу между пакетами. Рекомендуется оставить значение по умолчанию –2 миллисекунды.
- Выбрать тип контрольной суммы. Если тип определен неверно, ничего страшного, на прием пакетов это не влияет.
Параметр LIN CRC Type определяет тип используемой методики расчета контрольной суммы при работе с шиной LIN. На способность интерфейса принимать пакеты этот параметр не влияет. В случае если тип контрольной суммы определен неверно, то при передачи пакетов через интерфейс, принимающая сторона будет эти пакеты игнорировать.
Подключение к шине LIN осуществляется при помощи поставляемого с опцией анализатора LIN кабеля.
Назначение проводов LIN кабеля:
Красный – +12 В
Черный – Масса (GND)
Голубой – шина LIN
Либо по схеме:
Внимание! Подключение к шине LIN исследуемого устройства или автомобиля требует обязательного подключения массы (GND) и напряжения питания +12 В.
Если подключение и настройки сделаны верно и изучаемая шина LIN активна, т.е. происходит обмен данными между Master и Slave устройством, либо поступают запросы от Master узла, то в окне приема отобразятся передаваемые по шине LIN данные.
Подробное описание работы с программой CARBUS Analyzer в качестве анализатора LIN шины Вы найдете на отдельной странице – ссылка.
Читайте также: