В силу своей бывшей работы мне пришлось залезть с большое число CAN сетей различных автомобилей. Работа была в сфере создания противоугонных устройств и систем безопасности автомобилей. Часто было необходимо найти процедуры обмена данными и управления штатными устройствами по шине CAN. Как пример… допустим нам нужно при постановке в охрану закрыть штатный замок и поднять стекла. Необходимо найти в шине определенные ID и их порядок, содержимое и тайминги для того что бы штатные исполнительные механизмы срабатывали не только от BCM (Body Control Module) но и от команд с нашего устройства. Были задачки и посложнее … заблокировать работу двигателя… или наоборот дистанционно запустить двигатель ,без наличия ключа, для зимнего прогрева и при этом не нарушить работу штатной охраны , обеспечив защиту автомобиля с работающим двигателем. А для такой работы инструмент это первое дело. Но есть одна проблема. Приличный CAN анализатор это как правили коробочка с USB проводом , на конце которого болтается ноутбук. Автомобиль офис не затащишь и на стол его не положишь . Зимой и летом, сидеть часами в автомобиле окутанный проводами , с ноутом на коленях - это так себе занятие. А носить с собой ноутбук и CAN анализатор всюду и постоянно тоже надоедает. Да и функционал этих приборчиков не всегда удовлетворяет. Вот поэтому и решил я сделать себе свой CAN анализатор. Маленький, что бы носить в кармане, удобный по подключениям и что бы никакого windows.

Нужно было сделать некое устройство, которое безопасно для автомобиля позволит нам подключиться к CAN шине, считывать с нее информацию, фильтровать поступающий поток данных записывать ее в лог файлы. Это тот минимум , который необходим для старта работы с CAN шиной. Такие устройства называют снифферами (sniffer : нюхач — человек распознающий от оттенки запахов) . Вторым шагом можно дополнить такой пассивный сниффер возможностью активно вмешиваться в работу шины , а точнее записывать информацию с шину CAN. И третий режим, к которому неминуемо придет исследователь автомобильной CAN сети, это режим OBD тестера. Тестер — это устройство , которое подключено к шине и логически интегрировано в бортовую сеть. Т.е оно понимает протоколы обмена данными в сети и может взаимодействовать с другими блоками в сети по этим протоколам в целях диагностики и конфигурирования сети.

Общее описание анализатора.

Итак. Сделано компактное устройство на процессоре STM32 F103 , который позволяет решать следующие задачи. - чтение CAN фреймов нормального и расширенного типа на всех стандартных скоростях. - подключение к двухпроводным и однопроводным физическим реализациям CAN шины - запись логов взаимодействия с шиной автомобиля - гибкая установка фильтров для фильтрации потока данных - запись в шину отдельных фреймов в ручном режиме - запись в шину ранее записных или сформированных последовательностей CAN фреймов - исполнение программ скриптов встроенным интерпретатором языка C (правда в сильно упрощенном виде) . Скрипт исполняет программа клиент на базе Android устройства. - удобный визуальный контроль за процессами из приложения на Android.

Интерфейс построен на процессоре архитектуры STM32 F103 , который имеет в своем составе один CAN контроллер. Выход CAN контроллера спряжен со стандартным OBD коннектором через программно управляемый коммутатор. Это позволяет программно переключаться между шинами автомобиля. На выходе прибора стоят защищенные микросхемы CAN драйверов, что исключает некорректное аппаратное воздействие на шину автомобиля.

Для связи с приложением клиентом в устройство внедрен модуль Bluetooth HC-06, который обеспечивает скоростное соединение и гальваническою развязку с клиентом.

Приложение на Android служит для взаимодействия пользователя с устройством. Приложение поддерживает связь с устройством по каналу Bluetooth Classic c дальностью несколько десятков метров . Канал имеет контроль соединения . Приложение принимает поток данных от устройства и в удобном для пользователя виде отображает его на экране. Имеется возможность установить программно-аппартные фильтры для ограничения потока данных. Приложение пишет log файлы обмена данными. Написан встроенный интерпретатор с упрощенного языка C для управления процессом взаимодействия с устройством. Можно писать скрипты , которые будут выполнены во взаимодействии с автомобильной сетью.

Некоторые технические подробности.

Задача работы с CAN шиной на первый взгляд не так уж сложна, Но когда дело касается реальных автомобилей стоимостью в несколько тысяч долларов, то надо быть максимально осторожным , как и в плане программной работы , так на аппаратном уровне. Конечно спалить микросхемы в блоках авто , это надо очень сильно постараться, но для шаловливых ручек нет преград. Поэтому лучше подстраховаться и заложить в конструкцию устройства микросхемы (TJA1042T) драйверов CAN как и двухпроводного , так и однопроводого вариантов. Кроме того эти микросхемы обвесим диодными защитами PESD2CAN .

Устройство питается от автомобильной сети и полностью гальванически развязано от смартфона через канал Bluetooth.

Каналы выведены на стандартный OBD коннектор. CAN может быть с коммутирован на следующие пины разъема.

DWCAN (6-14), (3-11), (12-13) SWCAN 1 K-line 7, 8,9, 15 Поддерживаются все стандартные темпы CAN от 33 до 500 кБ /с.

В CAN анализаторах требуется относительно быстрый канал связи с клиентским устройством. Посмотрим на CAN кадр снятый прибором Saleae Logic. Моторная шина имеет темп обмена 500 кбит, что в реале соответствует около 250 mks на передачу одного фрейма. И канал связи должен соответствовать этому темпу.

Обычно эту проблему решают при помощи шнурка USB, но было выбрано другое беспроводное решение по озвученным выше причинам. Однако это означает, что модуль BT должен пропустить через себя темп не менее 460 кБит.с. А еще лучше иметь некоторый запас по пропускной способности канала. Формально ВТ модуль HC-06 поддерживает темп до 1382400 . Но поэкспериментировав с ним я пришел к выводу что не все так красиво как написано в документации по нему. При больших скоростях обмена в BT модуле видимо не хватает ресурсов по буферизации и модуль просто тихонько игнорирует часть входного потока данных пока он снова не будет готов к приему. Это отдельная проблема, которую надо решать переходя на канал WiFi c протоколом гарантированной доставки TCP. Но пока работаем с BT.

На плате устройства разведен выход на разъем USB. Но процессор F103 имеет такую особенность что одновременно работать USB и CAN не могут. Для канала USB была задумана функция обновления прошивки устройства. Но пока она так и не реализована, поскольку сам я обхожусь обычным программатором с SWD и нужды дистанционно обновлять прошивку устройства пока нет.

Программа для анализатора написана на C в среде IAR. Инициализация железа сделана при помощи Cube. Активно используются функции уровня драйвера HAL. Процессор обрабатывает прерывания по каналу CAN и принятые кадры пишет в очередь в ОЗУ. Далее фоновый процесс выбирает данные из этой очереди и отсылает их по каналу UART в BT модуль. Далее полученный поток данных принимается Android приложением и обрабатывается в нужном для пользователя виде. Управление устройством происходит так же по BT каналу при помощи нескольких терминальных команд. Этими командами можно настраивать устройство на заданный тип обмена, переключать каналы коммутатора и подключать CAN к различным пинам разъема OBD. Можно устанавливать и сбрасывать CAN фильтры.

Обзор Android приложения.

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

В интерфейсе приложения каждому потоку соответствует два элемента . Окно ввода команд и окно приема данных. Они образуют консоль управления потоком. Эти окна можно скрывать или активировать в настройках приложения в зависимости от решаемой задачи. Каждый поток может быть записан в лог файл путем касания checkbox в левом верхнем угла окна отображения данных. В верхней части экрана сделано окно состояний устройства, где отображается состояние связи с BT, контроль канала связи, текущий темп обмена по CAN, активный канал коммутатора CAN , режим работы устройства и тип и параметры протокола диагностики бортовой сети.

Проиллюстрируем работу устройства на простой но реальной задаче. Подключимся к моторной шине автомобиля Opel, снимем Log файл и прочитаем VIN номер.

В окне ввода можно задать CAN кадр, как стандартный , так и расширенный и послать этот кадр в шину. В окне приема виден список принятых и отосланных кадров с метками времени с точностью до 1 ms. Метки времени соответствуют реальным операциям на шине. Прочитиаем трафик и запишем Log файл моторной шины с полностью открытыми фильтрами.

Вот два скриншота из Log файла обозначающие начало и конец записи потока в 9.6 ~ (34.604-25.003) секунды с моторной шины Opel Astta J. Видно что за это время было снято 8120 CAN кадров. Далее в логе следует колоночка с метками времени с точностью 1 мс. Заметим, что это реальные метки времени снятые на стороне CAN шины, а не проставленные на стороне клиентского приложения, как это часто бывает в некоторых анализаторах. Видно что шина плотно заполонена данными и в одну миллисекунду иногда укладывается до 4 CAN кадров.

В этом режиме устройство работало как CAN сниффер и не вмешивалось в работу шины. Теперь усложним задачу . Попытаемся прочитать VIN номер по протоколу OBD-2. Для этого переведем устройство из режима Sniffer в Active , установим фильтры CAN для диапазона диагностического протокола и запишем в CAN кадр функционального запроса по ID 0x7DF c содержимым 020902.

Ответ нас удовлетворит лишь частично. Видно что начало ответного сообщения появилось на экране , но окончания нет. Дело в том что в этом режиме устройство хоть и может посылать CAN пакеты , но не является тестером, работающим по диагностическому протоколу. Что бы устройство корректно приняло пакеты от автомобиля, надо переключиться в режим тестера и тогда мы сможем работать в автомобилем уже не терминах CAN посылок , а в терминах OBD запросов.

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

Пока всю работу по настройке устройства на нужные нам режимы проводили вручную. Но что бы облегчить себе работу мы можем написать скрип, который можно будет исполнять интерпретатором на стороне Android.

В приложение встроен интерпретатор скриптов, который позволяет писать несложные программы на сильно упрощённом языке с синтаксисом С. Такой файл может быть загружен с телефона и тут же исполнен. Вот пример такого файла

В ней мы очищаем CAN фильтры, устанавливаем параметры связи и режим работы и отсылаем запрос VIN по OBD2.

Программы могут быть гораздо более сложными , с циклами и ветвлениями на основе принятых данных . Результат исполнения скрипта виден на скриншоте. Теперь мы уже только загружаем из памяти телефона файл VINreqODD.scs и исполняем его. Результат естественно такой же как если бы мы его вводили руками.

CAN plаyer.

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