Тестер can шины автомобиля
Анализатор CAN шины CANHacker
Не секрет, что в современном автомобиле управление многими исполнительными устройствами, а также обмен данных между различными ЭБУ (а их в автомобиле может быть довольно много, минимум по одному на каждую систему) осуществляется по CAN шине. Не буду в данной статье углубляться в теорию построения CAN шины и обмена данными в ней, ограничимся только тем, что мы CAN шину используем как транспорт для данных. Кому нужна более детальная информация по CAN шине, без труда найдет ее в любом поисковике.
Итак, какими исполнительными устройствами можно управлять по CAN? Список на самом деле может быть огромен, и может зависеть от конкретной марки и модели автомобиля. Для примера, по CAN может осуществляться снятие, постановка на охрану, складывание зеркал, управление стеклоподъемниками, срабатывание центрального замка, включение фар и т.д. Кстати, многие автомобильные девайсы подключаются к CAN шине, и путем передачи в шину определенных данных осуществлять какие-то действия. Например, по такому принципу работают доводчики стекол. Такой доводчик ждет появления в CAN шине данных на постановку на охрану, и при получении этих данных осуществляет передачу данных в CAN шину, которые инициируют закрытие стекол. Как правило, такие доводчики вставляются в OBD-2 разъем автомобиля, в котором имеется выход CAN шины. Тут следует сказать, что на автомобиле может быть несколько CAN шин (высокоскоростная, низкоскоростная), которые разделены между собой.
Сразу возникает вопрос, есть ли в машине CAN шина. Определить это можно, посмотрев в OBD2 разъем наличие пинов 6 и 14.
Что представляет собой CAN пакет с данными? Грубо говоря он представляет собой CAN ID (идентификатор CAN, может быть 11-ти или 29-ти битным) и данные DATA (в одном CAN пакете возможно передача до 8 байт). CAN ID — это фактически поле адресата, т.е. кому адресуются данные DATA. Несколько CAN пакетов могут образовывать одно сообщение (чтобы преодолеть лимит на передачу более 8-ми байт).
Каждому исполнительному устройству или датчику автопроизводитель назначает уникальный CANID (у разных производителей они будут разными), благодаря чему можно адресовать посылку данных конкретному ЭБУ или устройству, или получив CAN пакет ЭБУ может определить ему ли он предназначался, и если ему, то что он должен с ним сделать (например, в нашем примере с доводчиком — поднять стекло).
До этого была теория. Теперь я расскажу, как посмотреть, что творится в CAN шине автомобиля и что для этого нужно. Для этого необходим специальный адаптер и программа, которая будет отображать состояние CAN шины. Вообще, таких программ и адаптеров в природе существует много, но самым популярным является CANHacker (такой себе стандарт «де-факто»), поэтому про него я и расскажу. В качестве адаптера я буду использовать CHIPSOFT J2534 Lite адаптер, который может работать в режиме J2534 устройства, K-Line адаптера и в необходимом нам режиме CANHacker.
Сама программа CANHacker бесплатна и может быть без труда найдена на просторах интернета. Обращаю внимание на то, что по состоянию на март 2016, данная программа не может работать в Windows 10. Что-то Microsoft в своей операционке так улучшило, что в ней перестали работать все программы написанные ранее на Visual Basic c использованием COM порта.
Итак, запускаем программу, открываем окно настроек, в которых выбираем COM порт, на котором висит наше устройство, скорость обмена (в нашем случае 500 Kb/s), и режим работы (Listen Only).
Следует отметить, что если неправильно задать скорость CAN шины, которую собираемся слушать, то мы ничего не увидим. В автомобилях высокоскоростная CAN шина работает на скорости 500 Kb/s, ее и будем слушать, подключив наш CHIPSOFT J2534 Lite адаптер, в OBD2 разъем автомобиля.
Что еще нужно сказать по настройке Listen mode. Она определяет, требуется ли адаптером отсылать подтверждение приема CAN пакета. В нашем случае мы просто слушаем сеть и ничего не подтверждаем. Вообще, этот режим может быть полезен в том числе и в поиске неисправностей или обрывов в CAN шине.
Если предполагается отправка CAN пакетов в шину, то галка Listen Only должна быть снята.
Нажимаем старт. Если все сделано правильно, то на экране увидим CAN пакеты, которые «бегают» в сети нашего авто. А бегать их там может быть очень много. Так, на моей машине при заведенном двигателе «бегает» более 1000 пакетов в секунду. Вот какое происходит движение при подключении одиночного ЭБУ:
Если нам необходимо отследить какие-то конкретные CAN ID, то мы можем задать фильтр, который отсеет лишнее.
Программа CANHacker может работать в режиме монитора (monitor) и трейсера (tracer). В режиме монитора CAN пакеты сгруппированы по CAN ID и отображается переиод следлования данного CAN ID. В режиме трейсера отображается непрерывный поток CAN пакетов в порядке их появления в CAN шине. Но особенностью режима «трейсер» является то, что можно затем вопроизвести в шину в таком же порядке.
Также программа может отправлять отдельные CAN пакеты пользователя в CAN шину с заданным периодом (область в окне программы для работы в этом режиме называется Transmit). Некоторые используют это свойство для создания так называемой подмотки пробега. Т.к. информация о скорости вращения каждого колеса приходит с ЭБУ ABS, то отправляя непрерывно в шину CAN пакеты, в которых будет закодирована скорость, скажем 500 км/ч мы заставим одометр думать, что мы машина таки движется с такой скоростью, в результате чего счетчик пробега на одометре будет увеличиваться очень быстро а машина по факту стоять неподвижно.
В данной статье я сделал небольшой обзор программы CANHacker. Если тема интересная, то можно продолжить в меру моих знаний 🙂
Еще раз о диагностике CAN-шины
В предыдущей статье мы поговорили о проблемах в шине передачи данных CAN, возникших в результате износа аккумуляторной батареи и просадки питающего напряжения при запуске ниже порога работоспособности шины. Сегодня продолжим разговор о CAN-шине, но немного в другом ключе: прежде всего вспомним принцип ее работы, а затем рассмотрим один из случаев топологии шины и разберем осциллограмму дефекта.
Эта шина используется чаще всего как средство обмена данными в системах, для которых критично быстродействие и время принятия решения. Таковыми являются, например, система управления движением, объединяющая между собой блоки управления двигателем, автоматической трансмиссией, антиблокировочной системой тормозов, усилителем руля и т.п.
Конструктивно шина представляет собой неэкранированную витую пару. Провода шины называются CAN High и CAN Low.
Шина может находиться в двух состояниях:
Рассмотрим форму сигнала шины, чтобы обосновать ее помехоустойчивость:
На рисунке показаны доминантный и рецессивный уровни шины, а также воздействие на шину электромагнитной помехи. Особенностью обработки сигналов шины является то, что в расчет берется не сам уровень сигнала, а разница уровней между проводами CAN High и CAN Low. При рецессивном уровне эта разница близка к нулю, при доминантном уровне она максимальна.
В витой паре провода располагаются очень близко друг к другу. Если возникает внешняя электромагнитная помеха X, то она является синфазной и наводит одинаковый всплеск напряжения в обоих проводах шины. В итоге на обоих проводах появляется наведенный помехой импульс, но разница потенциалов между проводами при этом не меняется. Это позволяет эффективно подавлять внешние помехи, что является большим преимуществом CAN-шины.
На самом деле витая пара – давно известный способ борьбы с помехами. В медицине, например, в кардиостимуляторах, где требуется высочайшая помехоустойчивость, она применяется очень широко.
Сигнал шины поступает в блок управления на дифференциальный усилитель и обрабатывается. Иллюстрация поясняет процесс обработки:
Большинство автопроизводителей придерживаются скорости передачи 500 кБд, соответственно, продолжительность одного бита при этом составит 2 мкс.
Поговорим о топологии CAN-шины. Физически у шины нет начала и нет конца, шина – это просто единая сеть. Чаще всего встречаются два типа топологии: линейная топология и топология «пассивная звезда», а также их сочетания.
На современных автомобилях шина CAN очень разветвленная. Чтобы не перегружать линию большим количеством передаваемых данных, шина может состоять из нескольких ветвей, объединенных межсетевым шлюзом, иначе называемым Gateway. В итоге сеть представляет собой несколько ответвлений, в том числе и на диагностический разъем, использующих разную скорость и протоколы обмена.
Поэтому топология шины – вопрос для диагноста очень актуальный и, к сожалению, довольно сложный. Из тех электрических схем, которыми располагает диагност, не всегда можно понять топологию. Но в документации некоторых автопроизводителей приводится полная и подробная информация, в этом случае задача сильно упрощается.
Не зная тонкостей организации шины, найти в ней неисправность бывает достаточно сложно. Например, при наличии окисления контактов в разъеме пропадает связь с целым рядом блоков управления. Наличие под рукой топологии шины позволяет легко находить подобные проблемы, а отсутствие приводит к большой потере времени.
Ну что ж, мы немного освежили в памяти теорию шины, теперь самое время перейти к практике.
Нам повезло – Nissan относится к тому узкому кругу производителей, которые дают диагностам качественную и полноценную информацию. В том числе есть в документации и подробная топология бортовой шины обмена данными. Открываем, смотрим:
Следует сказать, что приведенная блок-схема достаточно общая. В документации имеется гораздо более подробная электрическая схема со всеми проводами и номерами контактов в блоках, но сейчас она нам пока что ни к чему, нам важно понять общую топологию.
Итак, первое, что нужно увидеть, это то, что вся сеть разделена на три большие ветви, обведенные пунктиром:
Первые две цепи связаны между собой посредством CAN gateway (найдите его на иллюстрации). Цепь шасси связана с цепью CAN 2 через блок управления шасси, который также играет роль своеобразного Gateway.
А теперь вновь обратимся к сканеру и посмотрим, какие из блоков управления не выходят на связь. Дилерский сканер предоставляет нам очень удобную функцию: на экран выводятся блоки каждой из цепей по отдельности, а цветом отображается возможность (зеленый) либо невозможность (красный) установить с ними связь. Вот блоки цепи CAN 1 :
Давайте обмерим ее с помощью линеек.
Просто идеальное соответствие теории и практики. Конечно, полосы пропускания нашего прибора явно недостаточно для корректного отображения сигнала, слишком уж широк его спектр. Однако, если закрыть на это глаза, то вполне можно оценить качество сигнала и сделать необходимые выводы.
Для наглядности масштаб осциллограмм на обеих иллюстрациях один и тот же.
То, что вы видите на этой осциллограмме, называется «мусор». Часто диагносты так и говорят: блок мусорит в шину. Вот только как найти блок, который это делает? Методика здесь очень проста и сводится она к поочередному отключению блоков и повторному наблюдению за сигналом шины.
Где именно находится тот или иной блок на автомобиле, в документации, как правило, показано. Например, на этом «финике» блоки расположены так:
Но в нашем случае все проще. Кстати, маленький лайфхак, возьмите на заметку. В автомобилях Nissan и Infiniti чаще всего причиной наличия мусора в CAN-шине является блок ABS. Сняв разъем с блока, сразу получаем нормальный обмен и связь сканера со всеми блоками ветви CAN 2 :
Обратите внимание на то, что связь в цепи CAN 2 есть со всеми блоками, кроме блока ABS, ведь он отключен.
Завершая разговор, хотелось бы обратить ваше внимание еще на один важный нюанс. Частота следования импульсов по CAN-шине составляет 500 кГц. Поэтому при получении осциллограммы необходимо задействовать максимально возможную частоту дискретизации мотортестера, на какую только он способен.
Если частоту дискретизации вы зададите низкую, то импульсы на осциллограмме будут сильно искажены. В качестве примера посмотрите, как выглядит осциллограмма сигнала CAN-шины при специально сниженной частоте дискретизации прибора:
CAN sniffer
CAN шина
Описывать технические подробности CAN шины в деталях — удел документации. В данной статье достаточно знать, что она:
Подключаюсь в диагностический разъём OBD (контакты 6 и 14) и смотрю осциллографом, что там имеется. После поворота ключа зажигания начинают бегать пакеты с амплитудой до 2,5 В. Ставлю паузу на осциллографе и смотрю на пакет.
Заметны стартовые и стоповые биты, какие-то данные в пакете. На тот момент я уже знал, что скорость передачи данных ожидается 500 кбит/с, как наиболее частая для моторной CAN шины. Длительность пакета получается около 230 мкс и перед пакетом наблюдается довольно большая пауза в передаче данных. Масштабирую время и вижу три пакета и паузы между ними.
Если сложить длительность передачи данных и паузу между пакетам получается, что передача одной порции данных занимает около 1 мс.
К чему я это всё вывожу? А вопрос чисто практический: хватит ли скорости последовательного порта для передачи всех данных? И исходя из увиденного, можно сделать вывод, что скорость 500 кбит/с развивается внутри пакета, который занимает примерно четверть времени на передачу. Значит средняя скорость передачи будет вчетверо меньшей. На тот момент я ещё не располагал тестами скорости последовательного интерфейса Arduino и забегая вперёд скажу, что даже с самым распространённым преобразователем Serial to USB CH340 стабильно работает скорость в 2 Мбит/с.
CAN scanner на Arduino
Первый прибыл шилд для классической Arduino UNO. Да он стоит значительно дороже своих более мелких собратьев, но он имеет на борту всё необходимое и даже две кнопки.
Именно с ним я и начал все эксперименты. Собрал простую схему с этим шилдом и жидкокристаллическим двухстрочным экраном. Цель была — вывести на экран хоть какие-то данные. Перебирал различные библиотеки для работы с CAN шиной на Arduino (сразу скажу, что правильная и рабочая библиотека называется CAN-BUS Shield by Seeed Studio с заголовочным файлом mcp_can.h), поменял кварцевый резонатор на шилде на 16 МГц (изначально стоял 8 МГц) — данных не было.
На шилде установлены две микросхемы: контроллер CAN шины MCP2515 и драйвер CAN шины TJA1050. Почитав документацию и различные форумы, решил поменять TJA1050 на более каноничный драйвер MCP2551 и данные появились. Возможно TJA1050 была изначально неисправна, так как с её подключением двумя проводками ошибиться было очень сложно, к тому же я использовал OBD и DB9 разъёмы для подключения.
За пару часов был написан простой CAN scanner, который выводил на жидкокристаллический дисплей номер захваченного пакета, его ID и до 8 байтов данных этого пакета.
Вот тут и пригодились кнопочки на шилде, которыми я реализовал переключение между номером отображаемого пакета.
Начало было положено, надо переходить к более интересной реализации.
CAN sniffer на Arduino
Задача стояла достаточно простая:
Для того, чтобы отправляемые данные корректно обрабатывались на стороне компьютера, перед каждой очередной порцией данных в поток вставляется префикс из четырёх байтов 0xAA55AA55 (почему-то вспомнились эти байты по последним двум байтам загрузочного сектора DOS, только они там были в другом порядке). Логика такая:
Так же я написал простой генератор пакетов данных для отладки, чтобы отлаживаться дома — он просто отправляет в последовательный порт пакеты со случайными данными, что позволяет отлаживать приложение на компьютере в комфортных условиях.
Примерно в это же время прибыли более миниатюрные компоненты Arduino Nano и Mini CAN shield.
Я спроектировал небольшой корпус, распечатал его и разместил внутри все компоненты.
Снаружи с одной стороны OBD разъём, с другой — Mini USB. Внутри имеется переключатель для терминирующего резистора.
CAN sniffer на PC с использованием wxWidgets
Ранее я в нескольких проектах использовал библиотеку wxWidgets и о ней у меня только приятные впечатления. Она легковесная, нет необходимости тащить с собой различные библиотеки и даже кросс-платформенная, что вселяет надежду, что интерфейсную часть кода можно перенести без значительных переделок на другие платформы. В конце статьи будет ссылка на скомпилированную программу, если возиться со всем этим не будет желания.
Можно скачать и посмотреть видео (менее восьми минут), а можно выполнить 6 шагов по описанию ниже.
Установка и компиляция wxWidgets:
1. Скачать и установить wxWidgets если это установщик, либо распаковать, если это архив
2. Создать переменную окружения WXWIN указывающую на папку, куда установили или распаковали (например C:\wxWidgets):
3. Из папки C:\wxWidgets\build\msw открыть файл решения под соответствующую Visual Studio (wx_vc16.sln для Visual Studio 2019)
4. В Solution Expolorer, с помощью клавиши Shift, выделить все проекты, кроме _custom_build и зайти в Properties проектов.
Для конфигурации Debug выбрать /MTd
Для конфигурации Release выбрать /MT
6. Скомпилировать библиотеки wxWidgets по очереди для Debug и Release конфигураций.
Пробное приложение и настройка проекта в Visual Studio (для проверки)
1. В Visual Studio создать Empty Project с указанием типа приложения Desktop Application (.exe)
3. Создать файл main.cpp и скопировать в него содержимое файла:
Runtime Library для конфигурации Debug: /MTd
Runtime Library для конфигурации Release: /MT
UAC Execution Level: requireAdministrator
6. Для добавления иконки exe-файлу надо добавить ресурсный файл со следующим содержимым:
#include «wx\msw\wx.rc»
wxicon icon app_icon.ico
Первый реализованный прототип на C++ и wxWidgets показал, что даже нетбук справляется с отображением данных в таблице и я приступил к разработке задуманного.
Архитектурно программа состоит из двух потоков: интерфейсный и поток работы с последовательным портом. Никаких невероятно интересных алгоритмов не применялось. Код обильно снабжён комментариями и должен быть довольно понятен. Ссылка на исходники будет в конце статьи.
Первое что было сделано — раскраска ячеек данных в таблице по давности получения этих данных. Уже в первом прототипе, глядя на 17 строк данных меняющихся непрерывно значений, я понял, что надо как-то различать свежие данные и данные, которые не изменяются или меняется редко. Сделал раскраску в два этапа:
Далее мне захотелось всё-таки проверить, справляется ли последовательный порт с потоком данных. Для этого я на стороне Arduino добавил счётчики количества принятых пакетов и счетчик байтов в пакете. Эти счётчики отправляются на компьютер в пакете с идентификатором 0x000. Программа при получении этих данных не выводит их в таблицу, а отображает в отдельных информационных полях сверху. Полученные результаты даже весьма понравились. В среднем принимается до 750 пакетов/с со скоростью до 9,5 кБ/с, а это где в районе до 80 кбит/с, что вполне по силам последовательному порту. Но всё равно, обмен данными настроен по умолчанию на 500 кбит/с, пусть лучше будет запас.
Добавление возможности записи данных в журнал появилось после того, как подключил параллельно к OBD интерфейсу диагностический адаптер ELM327 и связав его с телефоном, попробовал читать различные данные. Данные пробегали настолько быстро, что увидеть их невозможно. Записав всё это в журнал, можно потом спокойно сесть и посмотреть передаваемые данные. Для этого в журнал могут записываться даже ASCII текстовые данные. Так же можно выбирать тип файла, символ разделитель и настроить фильтр пакетов кликом в таблице по указанному идентификатору пакета и нажатию кнопки «Добавить ID в фильтр» (по умолчанию записываются все данные), если запись всех данных избыточна.
Именно тогда пришло осознание, что все приложения для телефона, которые производят всякую «диагностику» через связку ELM327 и телефон, не общаются напрямую с CAN шиной автомобиля. Они всего лишь используют функционал диагностики OBD через CAN шину посредством обращения к CAN ID 0x7E0. Обычно это адрес контроллера мотора (ЭБУ), ответ же от него приходит в пакете с идентификатором 0x7E8. А вот все остальные пакеты данных — это так называемый Vendor Specific и ни один производитель так просто их не раскроет (хотя есть пример: Ford выпустил SDK для своих автомобилей).
Продолжая изучать что же передаётся в этих пакетах пришёл к ещё одной идее: при клике на ячейку в таблице, в окне программы справа выводить двоичное и десятичное значение этого байта, а так же брать следующий байт и дополнять до слова. Далее это слово умножать на некий коэффициент и получить десятичный результат. Звучит не очень понятно, но вот в связи с чем это делалось: обороты мотора приходят в пакете CAN ID 0x180, в первых двух байтах. Эти два байта дают некое слово, которое пропорционально оборотам. Если значение этого слова разделить на 8, то получатся текущие обороты. Поэтому указывается множитель 0,125, как обратная величина от 8. Далее это слово визуализируется в графике с динамической подстройкой по амплитуде. В принципе, множитель можно искать в обратной последовательности: нашёл ячейки, которые по графику очень похожи на обороты мотора или ещё что-то искомое, после чего подгоняется множитель для получения действительных значений.
Ну а двоичное представление позволяет искать различные битовые индикаторы. Например поиск индикаторов указателей поворота сводится к тому, чтобы включить их и наблюдать какая ячейка начинает изменяться, в примере ниже это CAN ID 0x481 байт 2. После чего клик по ячейке приводит к отображению её двоичного значения в соответствующем поле, где уже видны переключающиеся младшие два бита (левый, правый и если вместе — аварийная сигнализация).
И напоследок мне понадобилось сделать отправку некоторых управляющих данных в CAN шину и посмотреть реакцию на эти команды. В программу на Arduino был добавлен код, который принимает данные со стороны компьютера и передаёт в CAN шину. Именно на этом этапе пришлось отказаться от CyberLib, так как у неё не было поддержки прерывания поступления данных в буфер последовательного порта. В программе на компьютере добавил несколько текстовых полей, в которые можно ввести различные параметры и таблицу для просмотра ответа исполнительного устройства. В примере ниже показаны команды управления включить/отключить первую скорость вентилятора охлаждения (0x0A) и включить/отключить муфту кондиционера (0x0B).
Практически нигде не найти полные расшифровки данных производителей, тем более официальных. В лучшем случае это будут чьи-то изыскания в рамках реализации какой-то дополнительной функции. CAN sniffer может помочь в поиске этих данных. Я смог найти порядка 40 различных параметров автомобиля и ради эксперимента, на базе полученных данных, я сделал собственное управление вентилятором охлаждения.