Хабрахабр

CAN sniffer

Непосредственно сама CAN шина используется уже много где, мне интересно её использование в автомобиле, хотя этой сферой можно и не ограничиваться. Тем более пару лет назад подвернулась такая возможность. Я посмотрел на общие спецификации — вроде бы ничего особо сложного нет. Посмотрел на программы, которые встречаются в интернете — и ни одна мне не приглянулась, у каждой не хватало чего-то такого, что казалось мне нужным на тот момент. Буду изобретать свой велосипед. Делаю свой CAN sniffer далее под катом.

CAN шина

Описывать технические подробности CAN шины в деталях — удел документации. В данной статье достаточно знать, что она:

  • имеет двухпроводное физическое подключение
  • бывают различные скорости передачи данных
  • для подключения уже имеются готовые микросхемы и даже готовые платы с распаянными деталями

Полистав странички одного известного интернет магазина из поднебесной, я заказал несколько различных вариантов шилдов и пошёл изучать особенности электрических сигналов в автомобиле. Подопытным автомобилем выступил LADA Kalina Cross с 127-ым мотором и электронным блоком управления ИТЭЛМА М74.5 CAN.

После поворота ключа зажигания начинают бегать пакеты с амплитудой до 2,5 В. Подключаюсь в диагностический разъём OBD (контакты 6 и 14) и смотрю осциллографом, что там имеется. Ставлю паузу на осциллографе и смотрю на пакет.

Заметны стартовые и стоповые биты, какие-то данные в пакете. На тот момент я уже знал, что скорость передачи данных ожидается 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 МГц) — данных не было.

Почитав документацию и различные форумы, решил поменять TJA1050 на более каноничный драйвер MCP2551 и данные появились. На шилде установлены две микросхемы: контроллер CAN шины MCP2515 и драйвер CAN шины TJA1050. Возможно TJA1050 была изначально неисправна, так как с её подключением двумя проводками ошибиться было очень сложно, к тому же я использовал OBD и DB9 разъёмы для подключения.

За пару часов был написан простой CAN scanner, который выводил на жидкокристаллический дисплей номер захваченного пакета, его ID и до 8 байтов данных этого пакета.

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

Про кнопочки

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

Начало было положено, надо переходить к более интересной реализации.

CAN sniffer на Arduino

Задача стояла достаточно простая:

  • принимаем пакет из CAN шины
  • укладываем полученные данные в свою структуру
  • отправляем структуру через последовательный порт

С первыми двумя задачами я вообще не видел никаких проблем. Библиотека предоставляла прерывание при приёме очередного пакета данных и удобные функции для получения данных. А вот отправку данных в сторону компьютера решил сделать через библиотеку CyberLib, которая устраняет некоторые накладные расходы всей платформы Arduino, за счёт чего можно немного разгрузить процессор для обработки данных. Позже от этой библиотеки пришлось отказаться.

Логика такая: Для того, чтобы отправляемые данные корректно обрабатывались на стороне компьютера, перед каждой очередной порцией данных в поток вставляется префикс из четырёх байтов 0xAA55AA55 (почему-то вспомнились эти байты по последним двум байтам загрузочного сектора DOS, только они там были в другом порядке).

  • компьютер читает весь поток из последовательного порта и находит в нём искомую последовательность префикса 0xAA55AA55
  • сразу после префикса будут 4 байта идентификатора пакета
  • далее длина данных этого пакета, по ней контролируется длина всего пакета
  • до 8 байтов данных

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

Так же я написал простой генератор пакетов данных для отладки, чтобы отлаживаться дома — он просто отправляет в последовательный порт пакеты со случайными данными, что позволяет отлаживать приложение на компьютере в комфортных условиях.

Примерно в это же время прибыли более миниатюрные компоненты Arduino Nano и Mini CAN shield.

Я спроектировал небольшой корпус, распечатал его и разместил внутри все компоненты.

Снаружи с одной стороны OBD разъём, с другой — Mini USB. Внутри имеется переключатель для терминирующего резистора.

CAN sniffer на PC с использованием wxWidgets

Набросал простую заготовку программы на C#, которая выводит в Grid получаемые данные. И пошёл проверять в автомобиль. Только пошёл не со своим ноутбуком, так как у него батарея давно приказала долго жить и использовался он как стационарный компьютер, а взял нетбук с очень слабым процессором. То что я увидел… Я ничего не увидел. Оба ядра загружены на 100%, интерфейс приложения не реагирует. Но на моём компьютере, который всё-таки значительно шустрее нетбука, с генератором случайных пакетов приложение нормально работало и отображало данные. Из этого я сделал вывод, что платформа .NET на слабых компьютерах мне не подойдёт, так как отлаживаться в полевых условиях я мог на тот момент только с тем нетбуком.

Она легковесная, нет необходимости тащить с собой различные библиотеки и даже кросс-платформенная, что вселяет надежду, что интерфейсную часть кода можно перенести без значительных переделок на другие платформы. Ранее я в нескольких проектах использовал библиотеку wxWidgets и о ней у меня только приятные впечатления. В конце статьи будет ссылка на скомпилированную программу, если возиться со всем этим не будет желания.

Как установить и скомпилировать wxWidgets для Visual Studio

Установка и компиляция
1. Скачать Windows Installer wxWidgets и установить, например, в папку C:\wxWidgets

Создать переменную окружения:
    WXWIN = C:\wxWidgets 2.

Запустить командную строку Visual Studio и перейти в директорию:
    %WXWIN%\build\msw 3.

Набрать две команды для компиляции:
    nmake /f makefile.vc BUILD=debug RUNTIME_LIBS=static
    nmake /f makefile.vc BUILD=release RUNTIME_LIBS=static 4.

В Visual Studio создать Win32 Project, с параметром Empty project. Настройка проекта в Visual Studio
1.

В свойствах проекта для All configuration прописать пути в разделе VC++ directories:
    Include Directories:
        $(WXWIN)\include
        $(WXWIN)\include\msvc 2.

    Library Directories:
        $(WXWIN)\lib\vc_lib

В разделе C/C++ — Code Generation изменить:
    Runtime Library для конфигурации Debug: /MTd
    Runtime Library для конфигурации Release: /MT 3.

В разделе General изменить:
    Character Set: Use Unicode Character Set 4.

Для добавления иконки exe-файлу надо добавить ресурсный файл со следующим содержимым:
    #include «wx\msw\wx.rc»
    wxicon icon app_icon.ico 5.

Дополнительно, если необходимы привелении UAC, в разделе Linker — Manifest File:
    UAC Execution Level: requireAdministrator
6.

Первый реализованный прототип на C++ и wxWidgets показал, что даже нетбук справляется с отображением данных в таблице и я приступил к разработке задуманного.

Никаких невероятно интересных алгоритмов не применялось. Архитектурно программа состоит из двух потоков: интерфейсный и поток работы с последовательным портом. Ссылка на исходники будет в конце статьи. Код обильно снабжён комментариями и должен быть довольно понятен.

Уже в первом прототипе, глядя на 17 строк данных меняющихся непрерывно значений, я понял, что надо как-то различать свежие данные и данные, которые не изменяются или меняется редко. Первое что было сделано — раскраска ячеек данных в таблице по давности получения этих данных. Сделал раскраску в два этапа:

  • впервые пришедшие данные выделяются зелёным цветом фона ячеек
  • данные пришедшие повторно и далее — выделяются красным фоном, который постепенно выцветает до белого если больше эти данные не меняются

Сразу же стало наглядно видно, какие ячейки вообще не используются, какие содержат сигналы счётчиков. Поиск же интересующих изменяющихся значений значительно упрощается. Здесь и далее все изображения анимированные. Если анимация не работает в статье (на некоторых мобильных браузерах) — кликайте по изображению для открытия полной версии анимации.

Для этого я на стороне Arduino добавил счётчики количества принятых пакетов и счетчик байтов в пакете. Далее мне захотелось всё-таки проверить, справляется ли последовательный порт с потоком данных. Программа при получении этих данных не выводит их в таблицу, а отображает в отдельных информационных полях сверху. Эти счётчики отправляются на компьютер в пакете с идентификатором 0x000. В среднем принимается до 750 пакетов/с со скоростью до 9,5 кБ/с, а это где в районе до 80 кбит/с, что вполне по силам последовательному порту. Полученные результаты даже весьма понравились. Но всё равно, обмен данными настроен по умолчанию на 500 кбит/с, пусть лучше будет запас.

Данные пробегали настолько быстро, что увидеть их невозможно. Добавление возможности записи данных в журнал появилось после того, как подключил параллельно к OBD интерфейсу диагностический адаптер ELM327 и связав его с телефоном, попробовал читать различные данные. Для этого в журнал могут записываться даже ASCII текстовые данные. Записав всё это в журнал, можно потом спокойно сесть и посмотреть передаваемые данные. Так же можно выбирать тип файла, символ разделитель и настроить фильтр пакетов кликом в таблице по указанному идентификатору пакета и нажатию кнопки «Добавить ID в фильтр» (по умолчанию записываются все данные), если запись всех данных избыточна.

Они всего лишь используют функционал диагностики OBD через CAN шину посредством обращения к CAN ID 0x7E0. Именно тогда пришло осознание, что все приложения для телефона, которые производят всякую «диагностику» через связку ELM327 и телефон не общаются напрямую с CAN шиной автомобиля. А вот все остальные пакеты данных — это так называемый Vendor Specific и ни один производитель так просто их не раскроет (хотя есть пример: Ford выпустил SDK для своих автомобилей). Обычно это адрес контроллера мотора (ЭБУ), ответ же от него приходит в пакете с идентификатором 0x7E8.

Далее это слово умножать на некий коэффициент и получить десятичный результат. Продолжая изучать что же передаётся в этих пакетах пришёл к ещё одной идее: при клике на ячейку в таблице, в окне программы справа выводить двоичное и десятичное значение этого байта, а так же брать следующий байт и дополнять до слова. Эти два байта дают некое слово, которое пропорционально оборотам. Звучит не очень понятно, но вот в связи с чем это делалось: обороты мотора приходят в пакете CAN ID 0x180, в первых двух байтах. Поэтому указывается множитель 0,125, как обратная величина от 8. Если значение этого слова разделить на 8, то получатся текущие обороты. В принципе, множитель можно искать в обратной последовательности: нашёл ячейки, которые по графику очень похожи на обороты мотора или ещё что-то искомое, после чего подгоняется множитель для получения действительных значений. Далее это слово визуализируется в графике с динамической подстройкой по амплитуде.

Ну а двоичное представление позволяет искать различные битовые индикаторы. Например поиск индикаторов указателей поворота сводится к тому, чтобы включить их и наблюдать какая ячейка начинает изменяться, в примере ниже это CAN ID 0x481 байт 2. После чего клик по ячейке приводит к отображению её двоичного значения в соответствующем поле, где уже видны переключающиеся младшие два бита (левый, правый и если вместе — аварийная сигнализация).

И напоследок мне понадобилось сделать отправку некоторых управляющих данных в CAN шину и посмотреть реакцию на эти команды. В программу на Arduino был добавлен код, который принимает данные со стороны компьютера и передаёт в CAN шину. Именно на этом этапе пришлось отказаться от CyberLib, так как у неё не было поддержки прерывания поступления данных в буфер последовательного порта. В программе на компьютере добавил несколько текстовых полей, в которые можно ввести различные параметры и таблицу для просмотра ответа исполнительного устройства. В примере ниже показаны команды управления включить/отключить первую скорость вентилятора охлаждения (0x0A) и включить/отключить муфту кондиционера (0x0B).

Итог

Практически нигде не найти полные расшифровки данных производителей, тем более официальных. В лучшем случае это будут чьи-то изыскания в рамках реализации какой-то дополнительной функции. CAN sniffer может помочь в поиске этих данных. Я смог найти порядка 40 различных параметров автомобиля и ради эксперимента, на базе полученных данных, я сделал собственное управление вентилятором охлаждения.
Надеюсь, что всё это будет полезно не только мне.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»