Краткий обзор протокола CAN. Часть I

Эта статья не претендует на полноту и абсолютную точность сведений, указанных в ней, и предназначена для ознакомления с протоколом CAN.

Содержание статьи

Шина CAN – Введение

Протокол CAN является стандартом ISO (ISO 11898) в области последовательной передачи данных. Протокол был разработан с прицелом на использование в транспортных приложениях. Сегодня CAN получил широкое распространение и используется в системах автоматизации промышленного производства, а также на транспорте.

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

Протокол CAN

Протокол CAN описан в стандарте ISO 11898–1 и может быть кратко охарактеризован следующим образом:

• физический уровень использует дифференциальную передачу данных по витой паре;

• для управления доступом к шине используется неразрушающее bit–wise разрешение конфликтов;

• сообщения имеют малые размеры (по большей части 8 байт данных) и защищены контрольной суммой;

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

• продуманная схема обработки ошибок, обеспечивающая повторную передачу сообщений, если они не были получены должным образом;
• имеются эффективные средства для изоляции сбоев и удаления сбойных узлов с шины.

Протоколы более высоких уровней

Сам по себе протокол CAN определяет всего лишь, как малые пакеты данных можно безопасно переместить из точки A в точку B посредством коммуникационной среды. Он, как и следовало ожидать, ничего не говорит о том, как управлять потоком; передавать большое количество данных, нежели помещается в 8–байтное сообщение; ни об адресах узлов; установлении соединения и т.п. Эти пункты определяются протоколом более высокого уровня (Higher Layer Protocol, HLP). Термин HLP происходит из модели OSI и её семи уровней.

Протоколы более высокого уровня используются для:

• стандартизации процедуры запуска, включая выбор скорости передачи данных;

• распределения адресов среди взаимодействующих узлов или типов сообщений;

• определения разметки сообщений;
• обеспечения порядка обработки ошибок на уровне системы.

Пользовательские группы и т.п.

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

Продукты CAN

На низком уровне принципиально различают два типа продуктов CAN, доступных на открытом рынке – микросхемы CAN и инструменты разработки CAN. На более высоком уровне – другие два типа продуктов: модули CAN и инструменты проектирования CAN. Широкий спектр данных продуктов доступен на открытом рынке в настоящее время.

Патенты в области CAN

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

Системы распределённого управления

Протокол CAN является хорошей основой для разработки систем распределённого управления. Метод разрешения конфликтов, используемый CAN, обеспечивает то, что каждый узел CAN будет взаимодействовать с теми сообщениями, которые относятся к данному узлу.

Систему распределённого управления можно описать как систему, вычислительная мощность которой распределена между всеми узлами системы. Противоположный вариант – система с центральным процессором и локальными точками ввода–вывода.

Сообщения CAN

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

Адресация сообщений CAN

CAN использует относительно короткие сообщения – максимальная длина информационного поля составляет 94 бита. В сообщениях отсутствует явный адрес, их можно назвать контентно–адрессованными: содержимое сообщения имплицитно (неявным образом) определяет адресата.

Типы сообщений

Существует 4 типа сообщений (или кадров), передающихся по шине CAN:

• кадр данных (Data Frame);

• удаленный кадр (Remote Frame);

• кадр ошибки (Error Frame);

• кадр перегрузки (Overload Frame).

Кадр данных

Кратко: «Всем привет, есть данные с маркировкой X, надеюсь вам понравятся!»
Кадр данных – самый распространенный тип сообщения. Он содержит в себе следующие основные части (некоторые детали не рассматриваются для краткости):

• Поле арбитража (Arbitration Field), которое определяет очередность сообщения в том случае, когда за шину борятся два или более узла. Поле арбитража содержит:

• В случае CAN 2.0A, 11–битный идентификатор и один бит, бит RTR который является определяющим для кадров данных.

• В случае CAN 2.0B, 29–битный идентификатор (который также содержит два рецессивных бита: SRR и IDE) и бит RTR.

• Поле данных (Data Field), которое содержит от 0 до 8 байт данных.

• Поле CRC (CRC Field), содержащее 15–битную контрольную сумму, посчитанную для большинства частей сообщения. Эта контрольная сумма используется для обнаружения ошибок.

• Слот распознавания (Acknowledgement Slot). Каждый контроллер CAN, способный корректно получить сообщение, посылает бит распознавания (Acknowledgement bit) в конце каждого сообщения. Приемопередатчик проверяет наличие бита распознавания и, если таковой не обнаруживается, высылает сообщение повторно.

Примечание 1: Присутствие на шине бита распознавания не значит ничего, кроме того, что каждый запланированный адресат получил сообщение. Единственное, что становится известно, это факт корректного получения сообщения одним или несколькими узлами шины.

Примечание 2: Идентификатор в поле арбитража, несмотря на свое название, необязательно идентифицирует содержимое сообщения.

Кадр данных CAN 2.0B («cтандартный CAN»).

Кадр данных CAN 2.0B («расширенный CAN»).

Удаленный кадр

Кратко: «Всем привет, кто–нибудь может произвести данные с маркировкой X?»
Удаленный кадр очень похож на кадр данных, но с двумя важными отличиями:

• он явно помечен как удаленный кадр (бит RTR в поле арбитража является рецессивным), и

• отсутствует поле данных.

Основной задачей удаленного кадра является запрос на передачу надлежащего кадра данных. Если, скажем, узел A пересылает удаленный кадр с параметром поля арбитража равным 234, то узел B, если он должным образом инициализирован, должен выслать в ответ кадр данных с параметром поля арбитража также равным 234.

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

Есть одна уловка, связанная с удаленным кадром: код длины данных (Data Length Code) должен быть установлен длине ожидаемого ответного сообщения. В противном случае разрешение конфликтов работать не будет.

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

Кадр ошибки (Error Frame)

Кратко (все вместе, громко): «О, ДОРОГОЙ, ДАВАЙ ПОПРОБУЕМ ЕЩЁ РАЗОК»
Кадр ошибки (Error Frame) – это специальное сообщение, нарушающее правила формирования кадров сообщения CAN. Он посылается, когда узел обнаруживает сбой и помогает остальным узлам обнаружить сбой – и они тоже будут отправлять кадры ошибок. Передатчик автоматически попробует послать сообщение повторно. Наличествует продуманная схема счетчиков ошибок, гарантирующая, что узел не сможет нарушить передачу данных по шине путём повторяющейся отсылки кадров ошибки.

Кадр ошибки содержит флаг ошибки (Error Flag), который состоит из 6 бит одинакового значения (таким образом нарушая правило вставки битов) и разграничителя ошибки (Error Delimiter), состоящего из 8 рецессивных бит. Разраничитель ошибки предоставляет некоторое пространство, в котором другие узлы шины могут отправлять свои флаги ошибки после того, как сами обнаружат первый флаг ошибки.

Вот флаг ошибки:

Кадр перегрузки (Overload Frame)

Кратко: «Я очень занятой 82526 маленький, не могли бы вы подождать минуточку?»
Кадр перегрузки упоминается здесь лишь для полноты картины. По формату он очень похож на кадр ошибки и передается занятым узлом. Кадр перегрузки используется нечасто, т.к. современные контроллеры CAN достаточно производительны, чтобы его не использовать. Фактически, единственный контроллер, который будет генерировать кадры перегрузки – это ныне устаревший 82526.

Стандартный и расширенный CAN

Изначально стандарт CAN установил длину идентификатора в поле арбитража равной 11 битам. Позже, по требованию покупателей стандарт был расширен. Новый формат часто называют расширенным CAN (Extended CAN), он позволяет использовать не менее 29 бит в идентификаторе. Для различения двух типов кадров используется зарезервированный бит в поле управления Control Field.

Формально стандарты именуются следующим образом –

• 2.0A – только с 11–битными идентификаторами;
• 2.0B – расширенная версия с 29–битными или 11–битными идентификаторами (их можно смешивать). Узел 2.0B может быть

• 2.0B active (активным), т.е. способным передавать и получать расширенные кадры, или

• 2.0B passive (пассивным), т.е. он будет молча сбрасывать полученные расширенные кадры (но, смотрите ниже).

• 1.x – относится к оргинальной спецификации и её ревизиям.

В настоящее время новые контроллеры CAN обычно относятся к типу 2.0B. Контроллер типа 1.x или 2.0A прибудет в замешательство, получив сообщения с 29 битами арбитража. Контроллер 2.0B пассивного типа примет их, опознает, если они верны и, затем – сбросит; a контроллер 2.0B активного типа сможет и передавать, и получать такие сообщения.

Контроллеры 2.0B и 2.0A (равно, как и 1.x) совместимы. Можно использовать их все на одной шине до тех пор, пока контроллеры 2.0B будут воздерживаться от рассылки расширенных кадров.

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

Основной CAN (Basic CAN) и полный CAN (Full CAN)

Термины Basic CAN и Full CAN берут начало в «детстве» CAN. Когда–то существовал CAN–контроллер Intel 82526, предоставлявший программисту интерфейс в стиле DPRAM. Потом появился Philips с моделью 82C200, в котором применялась FIFO–ориентированная модель программирования и ограниченные возможности фильтрации. Для обозначения различия между двумя моделями программирования, люди стали называть способ Intel – Full CAN, а способ Philips – Basic CAN. Сегодня большинство контроллеров CAN поддерживают обе модели программирования, поэтому нет смысла в использовании терминов Full CAN и Basic CAN – фактически, эти термины могут вызвать неразбериху и стоит воздержаться от их употребления.

В действительности, контроллер Full CAN может взаимодействовать с контроллером Basic CAN и наоборот. Проблемы с совместимостью отсутствуют.

Разрешение конфликтов на шине и приоритет сообщения

Разрешение конфликтов сообщений (процесс, в результате которого два или более контроллера CAN решают, кто будет пользоваться шиной) очень важно для определения реальной доступности полосы пропускания для передачи данных.

Любой контроллер CAN может начать передачу, когда обнаружит, что шина простаивает. Это может привести к тому, что два или более контроллеров начнут передачу сообщения (почти) одновременно. Конфликт решается следующим образом. Передающие узлы осуществляют мониторинг шины в процессе отправки сообщения. Если узел обнаруживает доминантный уровень в то время, как сам он отправляет рецессивный уровень, он незамедлительно устранится от процесса разрешения конфликта и станет приемником. Разрешение конфликтов осуществляется по всему полю арбитража, и после того, как это поле отсылается, на шине остается только один передатчик. Данный узел продолжит передачу, если ничего не случится. Остальные потенциальные передатчики попытаются передать свои сообщения позже, когда шина освободится. В процессе разрешения конфликта время не теряется.

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

Поскольку, CAN–шина является шиной с подсоединением устройств по типу «монтажное И» (wired–AND) и доминантный бит (Dominant bit) является логическим 0, следовательно сообщение с самым низким в численном выражении полем арбитража выиграет в разрешении конфликта.

Вопрос: Что произойдет в случае, если единственный узел шины попытается отослать сообщение?

Ответ: Узел, разумеется, выиграет в разрешении конфликта и успешно проведет передачу сообщения. Но когда наступит время распознавания… ни один узел не отправит доминантный бит области распознавания, поэтому передатчик определит ошибку распознавания, пошлет флаг ошибки, повысит значение своего счетчика ошибок передачи на 8 и начнет повторную передачу. Этот цикл повторится 16 раз, затем передатчик перейдет в статус пассивной ошибки. В соответствии со специальным правилом в алгоритме ограничения ошибок, значение счетчика ошибок передачи не будет более повышаться, если узел имеет статус пассивной ошибки и ошибка является ошибкой распознавания. Поэтому узел будет осуществлять передачу вечно, до тех пор, пока кто–нибудь не распознает сообщение.

Адресация и идентификация сообщения

Повторимся, нет ничего страшного в том, что в сообщениях CAN нет точных адресов. Каждый контроллер CAN будет получать весь траффик шины, и при помощи комбинации аппаратных фильтров и ПО, определять – «интересует» его это сообщение, или нет.

Фактически, в протоколе CAN отсутствует понятие адреса сообщения. Вместо этого содержимое сообщения определяется идентификатором, который находится где–то в сообщении. Сообщения CAN можно назвать «контентно–адрессовнными».

Определённый адрес работает так: «Это сообщение для узла X». Контентно–адресованное сообщение можно описать так: «Это сообщение содержит данные с маркировкой X». Разница между этими двумя концепциями мала, но существенна.

Содержимое поле арбитража используется, в соответствии со стандартом, для определения очередности сообщения на шине. Все контроллеры CAN будут также использовать всё (некоторые – только часть) поле арбитража в качестве ключа в процессе аппаратной фильтрации.

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

Примечание о значениях идентификатора

Мы говорили, что идентификатору доступны 11 (CAN 2.0A) или 29 (CAN 2.0B) бит. Это не совсем верно. Для совместимости с определенным старым контроллером CAN (угадайте каким?), идентификаторы не должны иметь 7 старших бит установленных в логическую единицу, поэтому 11–битным идентификаторам доступны значения 0..2031, а пользователи 29–битных идентификаторов могут использовать 532676608 различных значений.

Заметьте, что все остальные контроллеры CAN принимают «неправильные» идентификаторы, поэтому в современных системах CAN идентификаторы 2032..2047 могут использоваться без ограничений.

Физические уровни CAN

Шина CAN

Шина CAN использует код без возвращения к нулю (NRZ) с вставкой битов. Существуют два разных состояния сигнала: доминантное (логический 0) и рецессивное (логическая 1). Они соответствуют определенным электрическим уровням, зависящим от используемого физического уровня (их несколько). Модули подключены к шине по схеме «монтажное И» (wired–AND): если хотя бы один узел переводит шину в доминантное состояние, то вся шина находится в этом состоянии, вне зависмости от того, сколько узлов передают рецессивное состояние.

Различные физические уровни

Физический уровень определяет электрические уровни и схему передачи сигналов по шине, полное сопротивление кабеля и т.п.

Существует несколько различных версий физических уровней: • Наиболее распространенным является вариант, определенный стандартом CAN, часть ISO 11898–2, и представляющий собой двухпроводную сбалансированную сигнальную схему. Он также иногда называется high–speed CAN.

• Другая часть того же стандарта ISO 11898–3 описывает другую двухпроводную сбалансированную сигнальную схему – для менее скоростной шины. Она устойчива к сбоям, поэтому передача сигналов может продолжаться даже в том случае, когда один из проводов будет перерезан, замкнут на «землю» или в состоянии Vbat. Иногда такая схема называется low–speed CAN.

• SAE J2411 описывает однопроводной (плюс «земля», разумеется) физический уровень. Он используется в основном в автомобилях – например GM–LAN.

• Существуют несколько проприетарных физических уровней.

• В былые времена, когда драйверов CAN не существовало, использовались модификации RS485.

Различные физические уровни как правило не могут взаимодействовать между собой. Некоторые комбинации могут работать (или будет казаться, что они работают) в хороших условиях. Например, приемопередатчики high–speed и low–speed могут работать на одной шине лишь иногда.

Абсолютное большинство микросхем приемопередатчиков CAN произведено компанией Philips; в число других производителей входят Bosch, Infineon, Siliconix и Unitrode.

Наиболее распространен приемопередатчик 82C250, в котором реализован физический уровень, описываемый стандартом ISO 11898. Усовершенствованная версия – 82C251.

Распространенный приемопередатчик для «low–speed CAN» – Philips TJA1054.

Максимальная скорость передачи данных по шине

Максимальная скорость передачи данных по шине CAN, в соответствии со стандартом, равна 1 Мбит/с. Однако некоторые контроллеры CAN поддерживают скорости выше 1 Мбит/с и могут быть использованы в специализированных приложениях.

Low–speed CAN (ISO 11898–3, см. выше) работает на скоростях до 125 кбит/с.

Однопроводная шина CAN в стандартном режиме может передавать данные со скоростью порядка 50 кбит/с, а в специальном высокоскоростном режиме, например для программирования ЭБУ (ECU), около 100 кбит/с.

Минимальная скорость передачи данных по шине

Имейте в виду, что некоторые приемопередатчики не позволят вам выбрать скорость ниже определенного значения. Например, при использовании 82C250 или 82C251 вы можете без проблем установить скорость 10 кбит/с, но если вы используете TJA1050, то не сможете установить скорость ниже 50 кбит/с. Сверяйтесь со спецификацией.

Максимальная длина кабеля

При скорости передачи данных 1 Мбит/с, максимальная длина используемого кабеля может составлять порядка 40 метров. Это связано с требованием схемы разрешения конфликтов, согласно которому фронт волны сигнала должен иметь возможность дойти до самого дальнего узла и вернуться назад прежде чем бит будет считан. Иными словами, длина кабеля ограничена скоростью света. Предложения по увеличению скорости света рассматривались, но были отвергнуты в связи с межгалактическими проблемами.

Другие максимальные длины кабеля (значения приблизительные):

• 100 метров при 500 кбит/с;

• 200 метров при 250 кбит/с;

• 500 метров при 125 кбит/с;
• 6 километров при 10 кбит/с.

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

Оконечное прерывание шины

Шина CAN стандарта ISO 11898 должна заканчиваться терминатором. Это достигается путем установки резистора сопротивлением 120 Ом на каждом конце шины. Терминирование служит двум целям:

1. Убрать отражения сигнала на конце шины.

2. Убедиться, что получает корректные уровни постоянного тока (DC).

Шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Я повторю: шина CAN стандарта ISO 11898 обязательно должна терминироваться вне зависимости от её скорости. Для лабораторной работы может хватить и одного терминатора. Если ваша шина CAN работает даже при отсутствии терминаторов – вы просто счастливчик.

Заметьте, что другие физические уровни, такие как low–speed CAN, однопроводная шина CAN и другие, могут требовать, а могут и не требовать наличия оконечного терминатора шины. Но ваша высокоскоростная шина CAN стандарта ISO 11898 всегда будет требовать наличия хотя бы одного терминатора.

Кабель

Стандарт ISO 11898 предписывает, что волновое сопротивление кабеля номинально должно равнятся 120 Ом, однако допускается интервал значений сопротивления [108..132] Ом.

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

ISO 11898 описывает витую пару, экранированную или неэкранированную. Идёт работа над стандартом однопроводного кабеля SAE J2411.

CAN-технология BOSCH в диагностике автомобилей

CAN Технологии
Применяемая на автомобилях система CAN (Controller_Area_Network) позволяет установить связь между отдельными электронными блоками управления. При эксплуатации автомобиля и при диагностике его агрегатов эта система предоставляет возможность использования новых функций, которые не могут быть возложены на отдельно действующие блоки управления.
Применяемая на автомобилях система CAN позволяет объединить в локальную сеть электронные блоки управления или сложные датчики, как, например, датчик угла поворота рулевого колеса. Обозначение CAN является сокращением от выражения Controller:Area:Network (локальная сеть, связывающая блоки управления). Применение системы CAN на автомобиле дает следующие преимущества:
Обмен данными между блоками управления производится на унифицированной базе. Эту базу называют протоколом. Шина CAN служит как бы магистралью для передачи данных.
Независимо действующие системы, например, система курсовой стабилизации ESP, могут быть реализованы с меньшими затратами.
Упрощается подключение дополнительного оборудования.
Шина данных CAN является открытой системой, к которой могут быть подключены как медные провода, так и стекловолоконные проводники.
Диагностика электронных блоков управления производится посредством кабеля «К».
Диагностика некоторых компонентов оборудования салона автомобиля уже сегодня производится через шину CAN (например, это подушки безопасности и блоки управления в дверях автомобиля). В данном случае речь идет о так называемом виртуальном кабеле «К». В будущем необходимость в кабеле «К» должна отпасть.
Можно проводить одновременную диагностику нескольких блоков управления, входящих в систему.
CAN
Промышленная сеть CAN (Controller Area Network) была создана в конце 80-х годов фирмой Bosch как решение для распределенных систем, работающих в режиме реального времени. Первая реализация CAN применялась в автомобильной электронике, однако сейчас CAN находит применение практически в любых типах машин и промышленных установок, от простейших бытовых приборов до систем управления ускорителями элементарных частиц. В настоящий момент CAN-протокол стандартизован в международном стандарте ISO 11898.

Основные положения стандарта CAN.
В качестве среды передачи в CAN используется дифференциальная линия связи — витая пара, сигналы по которой передаются в дифференциальном режиме.
Для контроля доступа к среде передачи используется метод недеструктивного арбитража.
Данные передаются короткими (максимальная длина поля данных — 8 байт) пакетами, которые защищены контрольной суммой.
В CAN отсутствует явная адресация сообщений. Вместо этого каждый пакет снабжен полем арбитража (идентификатор+RTR-бит), которое задает приоритет сообщения в сети.
CAN имеет исчерпывающую схему контроля ошибок, которая гарантирует повторную передачу пакета, в случае возникновения ошибок передачи/приема сообщения.
В CAN существует способ автоматического устранения узла, являющегося источником ошибочных пакетов в сети.
CAN контроллеры.
Протокол CAN полностью реализован аппаратно — в виде микросхем- CAN контроллеров или в виде стандартного периферийного устройства в составе микросхемы- микроконтроллера. Все производители современных микроконтроллеров по крайней мере в одном из семейств имеют микроконтроллеры со встроенным периферийным одним или несколькими CAN-контроллерами. Таким образом, сегодня, СAN-контроллер является таким же стандартным периферийным устройством как контроллер SPI, I2C или UART.
Что такое CAN-шина
Для повышения надежности в CAN-шине используется принцип дифференциальной передачи данных, требующий двух проводов, CAN-High (CAN-H) высокий и CAN-Low (CAN-L) низкий уровень напряжения.
Рецессивные и доминантные биты
Для повышения надежности в CAN-шине используется принцип дифференциальной передачи данных, требующий двух проводов, CAN-High (CAN-H) высокий и CAN-Low (CAN-L) низкий уровень напряжения.

Как это исполнено физически
Физически CAN-шина – система из специального кабеля с разветвителями для подключения электронных блоков и конечных устройств-терминаторов (резисторов).

Витая пара
Чаще всего шина CAN – скрученные (витые) пары проводов (по 30 витков на один погонный метр) с разветвителями для подключения ЭБУ (ECU) и конечными резисторами-терминаторами с номинальным сопротивлением 120 Ом на концах шины.
Сколько CAN-шин может быть на ТС
На ТС экологического уровня Евро-3 и выше может быть от 1 до 6 и более шин CAN, которые могут обозначаться как M-CAN, T-CAN, I-CAN, H-CAN, A-CAN, EBS-CAN и т.д.

Как найти CAN-шину
Признаками шины М-CAN и Т-CAN могут быть, например:
• наличие диагностического разъема OBD II;
• цвет и сечение проводов витых пар;
• связь витых пар с контактами в разъемах OBD II и ЭБУ.

Диагностический разъём OBD II и его распиновка
На большинстве ТС после 2003 года используется диагностический разъем OBD II или DLC (Diagnostic Link Connector), который находится под панелью приборов.

Как будем искать CAN-шину
С помощью мультиметра можно проверить любую витую пару проводов, чтобы убедиться в следующем:
1. Является ли проверяемая витая пара вообще CAN-шиной? (Проверка импеданса);
2. Если витая пара является CAN-шиной, то передаются ли в ней какие–либо сообщения? Проверка работоспособности);
3. Находится ли CAN-шина в работоспособном состоянии и какая из линий шины является CAN-L, а какая – CAN-H?

Внимание! Неосторожное обращение с включенной
CAN-шиной может привести к фиксации в ней ошибок!

Проверка импеданса
Проверка импеданса (полного сопротивления)

ВНИМАНИЕ!
Проверка должна производиться при полностью выключенном питании бортовой сети (выключенной массе).
Контрольное значение должно быть в пределах 60 Ом.

Проверка работоспособности CAN-шины
Находится ли CAN-шина в рабочем состоянии?

ВНИМАНИЕ! Проверка производится при включенном замке зажигания, работающем двигателе, нажатии и отпускании педали подачи топлива между проводами витой пары.
Контрольное значение напряжения должно быть в пределах 1,2-3,0 В.

Определение CAN-H и CAN-L
Какой из проводов является CAN-H, а какой CAN-L?

ВНИМАНИЕ! Проверка производится в состоянии рецессии (при включенном главном выключателе АКБ (кнопке массы), замок зажигания выключен!) и в доминантном состоянии (при включенном замке зажигания в положение «Приборы», при работающем и не работающем двигателе).
Проверка с помощью осциллографа
Учитывая возможные отклонения уровня напряжения от номинальных значений, состояние рецессии можно определить только с помощью осциллографа.

Цвет оболочки и цветовая маркировка проводов

CAN-шина. Что можно увидеть?
В зависимости от того, какую информацию заложил в CAN-шину производитель, могут распознавать:
Способы подключения:

Контактный способ:
Достоинства:
• просто и дешево;
• можно работать на считывание и передачу.
Недостатки:
• может оказывать мешающее влияние на CAN-шину; проблемы с возникновением и фиксацией ошибок;
• Проблемы с гарантией на ТС.

Безконтактный способ (CANCrocodile):

Достоинства:
• не оказывает мешающего воздействия на CAN-шину.
Недостатки:
• можно работать только на считывание.

Бесконтактныe считыватели Crocodile
CAN Crocodile – устройство для бесконтактного считывания данных с CAN-шины автомобиля. CAN Crocodile применяется для подключения к шине CAN систем GPS/ГЛОНАСС мониторинга, которые получают информацию о режимах работы двигателя, состоянии датчиков, уровне топлива, наличии неисправностей и т.д. CAN Crocodile не нарушает изоляцию проводов CAN и «слушает» обмен по шине с помощью специального беспроводного приемника. Применение CAN Crocodile абсолютно безопасно для автомобиля (!), незаметно для работы бортового компьютера, диагностического сканера и других электронных систем. Особенно актуально применение CAN Crocodile для гарантийных автомобилей, в которых подключение каких-либо электронных устройств к шине CAN часто служит поводом для снятия с гарантии.

Бесконтактным способом – без нарушения изоляционной оболочки проводов и электрического контакта.
Не нарушает изоляцию;
Не влияет на работу CAN-шины;
Не занимает диагностический разъём

Управление автомобилем по CAN

Беспилотный автомобиль StarLine на платформе Lexus RX 450h — научно-исследовательский проект, стартовавший в 2018 году. Проект открыт для амбициозных специалистов из Open Source Community. Мы предлагаем всем желающим поучаствовать в процессе разработки на уровне кода, опробовать свои алгоритмы на реальном автомобиле, оснащенном дорогостоящим оборудованием. Для управления автомобилем было решено использовать Apollo, открытый фреймворк. Для работы Apollo нам необходимо было подключить набор модулей. Эти модули помогают программе получать информацию об автомобиле и управлять им по заданным алгоритмам.

К таким модулям относятся:

• модуль позиционирования автомобиля в пространстве с помощью GPS-координат;
• модуль управления рулем, ускорением и торможением авто;
• модуль состояния систем автомобиля: скорость, ускорение, положение руля, нажатие на педали и т.д.;
• модуль получения информации об окружении автомобиля. С этим справятся ультразвуковые датчики, камеры, радары и лидары.

Теоретическая часть

Что такое CAN-шина

В современных автомобилях управление всеми системами взяли на себя электронные блоки (Рис. 1.). Электронные блоки — это специализированные компьютеры, каждый из которых имеет все необходимые интерфейсы для интеграции с автомобилем. С помощью цифровых интерфейсов связи, блоки объединяются в сеть для обмена информацией друг с другом. Самые распространенные цифровые интерфейсы в автомобилях — CAN, LIN, FLEXRay. Из них наибольшее распространение получил именно CAN.

CAN (Controller Area Network) шина — это промышленный стандарт сети. В 1986 году этот стандарт разработали в компании Bosch. А первым автомобилем с CAN-шиной стал Mercedes-Benz W140, выпущенный в 1991 году. Стандарт разрабатывался для возможности устройствам общаться друг с другом без хоста. Обмен информацией осуществляется с помощью специальных сообщений, которые состоят из полей ID, длины сообщения и данных. Каждый блок имеет свой набор ID. При этом приоритет на шине имеет сообщение с меньшим ID. Поле данных может нести информацию, например, о состоянии систем и датчиков, команды управления механизмами и т.д.

Рис. 1. Шина CAN автомобиля.

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

Рис. 2. Физическое представление сигнала в CAN шине

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

Мы выбрали Lexus RX, потому что знали, что сможем управлять всеми необходимыми узлами по CAN. Так как самое сложное при исследовании автомобиля — это закрытые протоколы. Поэтому одной из причин выбора именно этой модели авто стало наличие описания части протокола CAN-шины в opensource-проекте Openpilot.

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

Электроусилитель руля

Электроусилитель руля EPS (Electric Power Steering) — система, предназначенная снизить усилие на руль при повороте (Рис. 3). Приставка «электро» говорит о типе системы — электрическая. Управление рулем с этой системой становится комфортным, водитель поворачивает руль в нужном направлении, а электродвигатель помогает довернуть его до необходимого угла.

Электроусилитель устанавливается на рулевой вал автомобиля, части которого соединены между собой торсионным валом. На торсионный вал устанавливается датчик величины крутящего момента (Torque Sensor). При вращении руля происходит скручивание торсионного вала, которое регистрируется датчиком момента. Данные, полученные от датчика момента, датчиков скорости и оборотов коленвала, поступают в электронный блок управления ECU. А ECU, в свою очередь, уже вычисляет необходимое компенсационное усилие и подает команду на электродвигатель усилителя.

Рис. 3. Схематичное изображение системы электроусилителя руля

Видео: cистема LKA рулит автомобилем с помощью системы EPS.

Электронная педаль газа

Дроссельная заслонка — это механизм регулировки количества топливной смеси, которая попадет в двигатель. Чем больше смеси попадет, тем быстрее едет автомобиль.
Электронная педаль газа — это система, которая задействует работу нескольких электронных узлов. Сигнал о положении педали, при ее нажатии, поступает в блок управления двигателем ECM (Engine Control Module). ECM, на основе этого сигнала, рассчитывает необходимое количество топлива, которое нужно подать в двигатель. В зависимости от необходимого количества топлива, ECM регулирует угол открытия дроссельной заслонки.

Рис. 4. Система электронной педали газа.

Видео: Для работы круиз-контроля используется управление электронной педалью газа.

Электронные системы помощи водителю

Мы купили автомобиль, который оборудован множеством цифровых блоков и систем помощи водителю (ADAS). В нашем проекте мы используем LKA, ACC и PCS.

LKA (Lane Keep Assist) — это система удержания в полосе, которая состоит из фронтальной камеры и вычислительного блока. LKA удерживает автомобиль в полосе движения, когда водитель, например, отвлекся. Алгоритмы в вычислительном блоке получают данные от камеры и на их основе принимают решение о состоянии автомобиля на дороге. Система способна понимать, что автомобиль неконтролируемо движется к правой или левой полосе. В таких случаях подается звуковой сигнал для привлечения внимания водителя. При пересечении полосы система сама скорректирует угол поворота колес так, чтобы автомобиль остался в полосе движения. Система должна вмешиваться только в том случае, если осознает, что маневр между полосами движения не был вызван действием водителя.

ACC (Adaptive Cruise Control) — система адаптивного круиз-контроля, который позволяет выставить заданную скорость следования. Автомобиль сам ускоряется и притормаживает для поддержания нужной скорости, при этом водитель может убрать ногу с педалей газа и тормоза. Этот режим удобно использовать при езде по скоростным магистралям и автострадам. Адаптивный круиз контроль способен видеть препятствия впереди автомобиля и притормаживать для избежания столкновения с ними. Если впереди автомобиля едет другое транспортное средство с меньшей скоростью, ACC сбавит скорость и будет следовать за ним. При обнаружении статичного объекта, ACC сбавит скорость до полной остановки. Для обнаружения объектов перед автомобилем такая система использует радар с миллиметровым диапазоном длин волн. Обычно такие радары работают на частоте 24-72 ГГц и способны уверенно видеть объекты на расстоянии до 300 метров. Радар обычно установлен за передним значком на решетке радиатора.

PCS (Pre-Collision System) — система предотвращения столкновения. Система призвана предотвратить столкновение с автомобилем, который движется впереди. При неизбежности столкновения, система минимизирует урон от столкновения. Здесь так же используются радар для оценки расстояния до объекта и фронтальная камера для его распознавания. Фронт PCS прогнозирует вероятность столкновения на основе скорости автомобиля, расстояния до объекта и его скорости. Обычно у системы есть два этапа срабатывания. Первый этап — система звуком и индикацией на приборной панели оповещает об опасности водителя. Второй этап — активируется экстренное торможение с помощью системы ABS, и включаются преднатяжители ремней безопасности.

Практическая часть

Управление рулем

Первое, что захотелось сделать нашей команде, — это научиться рулить. Рулем в автомобиле могут управлять две системы: парковочный ассистент IPAS (Intelligent Park Assist) и LKA.

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

Поэтому мы изучили электрические схемы автомобиля и поняли, какие CAN-шины могут быть полезны. Мы подключили анализатор CAN-шины. Лог содержит файл записей сообщений в шине в хронологической последовательности. Наша задача была найти команды управления электроусилителем руля EPS (Electric Power Steering). Мы сняли лог поворота рулевого колеса из стороны в сторону, в логе смогли найти показания угла поворота и скорость вращения рулевого колеса. Ниже пример изменения данных в шине CAN. Интересующие нас данные выделены маркером.

Поворот руля влево на 360 градусов

Поворот руля вправо на 270 градусов

Следующим этапом мы исследовали систему удержания в полосе. Для этого мы выехали на тихую улицу и записали логи обмена между блоком удержания в полосе и DSU (Driving Support ECU). С помощью анализатора шины CAN нам удалось вычислить сообщения от системы LKA. На рисунке 6 изображена команда управления EPS.

Рис. 5. Команда управления рулем с помощью системы LKA

LKA управляет рулем путем задания значения момента на валу (STEER_TORQUE_CMD) рулевого колеса. Команду принимает модуль EPS. Каждое сообщение содержит в заголовке значение счетчика (COUNTER), которое инкрементируется при каждой отправке. Поле LKA_STATE содержит информацию о состоянии LKA. Для захвата управления необходимо выставлять бит STEER_REQUEST.

Сообщения, которые отвечают за работу важных систем авто, защищаются контрольной суммой (CHECKSUM) для минимизации рисков ложного срабатывания. Автомобиль проигнорирует такую команду, если сообщение содержит некорректную контрольную сумму или значение счетчика. Это встроенная производителем защита от вмешательств сторонних систем и помех в линии связи.

На графике (Рис. 6.) представлена диаграмма работы LKA. Torque Sensor — значение с датчика момента на торсионном валу. Torque Cmd — команда от LKA для управления рулем. Из картинки видно, как происходит подруливание LKA для удержания автомобиля в полосе. При переходе через ноль меняется направление поворота руля. Т.е. отрицательное значение сигнала говорит о повороте вправо, положительное — влево. Удержание команды в нуле говорит об отсутствии управления со стороны LKA. При вмешательстве водителя, система перестает выдавать управление. О вмешательстве водителя LKA узнает с помощью второго датчика момента на валу со стороны рулевого колеса.

Рис. 6. График работы системы LKA

Нам предстояло проверить работу команды управления рулем. С помощью модуля StarLine Сигма 10 мы подготовили прошивку для проверки управления. StarLine Сигма 10 должен выдавать в CAN-шину команды на поворот руля влево или вправо. На тот момент у нас не было графического интерфейса для управления модулем, поэтому пришлось использовать штатные средства автомобиля. Мы нашли в CAN-шине статус положения рычага круиз-контроля и запрограммировали модуль таким образом, что верхнее положение рычага приводило к повороту руля вправо, нижнее положение — к повороту влево (Рис. 7).

Рис. 7. Первые попытки рулить

На видео видно, что управление осуществляется короткими секциями. Это возникает по нескольким причинам.

Первая из причин — это отсутствие обратной связи. Если расхождение между сигналом Torque Cmd и Torque Sensor превышает определенное значение Δ, система автоматически перестает воспринимать команды (Рис. 8). Мы настроили алгоритм на корректировку выдаваемой команды (Torque CMD) в зависимости от значения момента на валу (Torque Sensor).

Рис. 8. Расхождение сигнала приводит к ошибке работы системы

Следующее ограничение связано с системой защиты встроенной в EPS. Система EPS не позволяет командами от LKA рулить в широком диапазоне. Что вполне логично, т.к. при езде по дороге резкое маневрирование не безопасно. Таким образом, при превышении порогового значения момента на валу, система LKA выдает ошибку и отключается (Рис. 9).

Рис. 9. Превышение порогового значения регулировки момента на валу

Независимо от того, активирована система LKA или нет, сообщения с командами от нее присутствуют в шине постоянно. Мы посылаем модулю EPS команду повернуть колеса с конкретным усилием влево или вправо. А в это время LKA перебивает наши посылки «пустыми» сообщениями. После нашей команды со значением момента, приходит штатная с нулевым (Рис. 10).

Рис. 10. Штатные сообщения приходят с нулевыми значениями момента и перебивают наше управление

Тогда мы, с помощью модуля StarLine Сигма 10, смогли фильтровать весь трафик от LKA и блокировать сообщения с ID 2E4, когда нам это было нужно. Это решило проблему, а нам удалось получить плавное управления рулем (Рис. 11).

Рис. 11. Плавная регулировка поворота руля без ошибок

Управление газом

Система адаптивного круиз-контроля ACC управляет ускорением и торможением программно по CAN-шине. Блок управления двигателем ECU принимает команды DSU, если необходимо ускориться — активирует электронную педаль газа. Для торможения автомобиля используется рекуперативное торможение. При этом на торможение и ускорение используется одна команда, отличаются только значения.

Команда управления ускорением или замедлением представлена на рисунке 12. Она состоит из величины ускорения ACCEL_CMD, пары служебных бит и контрольной сумма Checksum. Для ускорения автомобилем значение ACCEL_CMD положительное, для замедления — отрицательное. Ускорение задается в диапазоне от 0 до 3 м/с^2, замедление аналогично, но со знаком минус. Для отправки данных в шину необходимо пересчитать желаемое ускорение или замедление с коэффициентом 0,001. Например, для ускорения 1 м/с^2, ACCEL_CMD = 1000 (0x03E8).

Рис. 12. Команда управления ускорения/замедления автомобиля

Мы сняли логи со штатной системы ACC и проанализировали команды. Сравнили с имеющимся у нас описанием команд и приступили к тестированию.

Рис. 13. Лог управления ускорением/замедлением системы адаптивного круиз-контроля ACC (выделено маркером)

Здесь не обошлось без трудностей. Мы выехали на дорогу с оживленным трафиком для тестирования команды ускорения. Команды управления ускорением или замедлением автомобиля работают только при активированном круиз контроле, не достаточно активировать его кнопкой. Необходимо найти движущийся впереди автомобиль и включить режим следования за ним.

Рис. 14. Активация круиз контроля происходит при наличии впереди другого траснпортного средства

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

Команды работали до тех пор, пока не потеряли автомобиль впереди. Система круиз-контроля отключилась, а следовательно, и команды ускорения перестали работать.
Мы приступили к исследованию возможности использовать команды без активного круиз-контроля. Пришлось много времени потратить на анализ данных в шине CAN, чтобы понять как создать условия для работы команд. Нас интересовало, в первую очередь, какой блок блокирует выполнение команд ACC на ускорение или замедление. Пришлось изучить какие ID идут от DSU, LKA, радара и камеры, подсовывая липовые данные различных датчиков.

Решение пришло спустя 3 недели. К тому времени мы представляли как происходит взаимодействие блоков автомобиля, провели исследование трафика сообщений и выделили группы сообщений, посылаемых каждым блоком. За работу адаптивного круиз-контроля ACC отвечает блок Driving Support ECU (DSU). DSU выдает команды на ускорение и замедление автомобиля, и именно этот блок получает данные от радара миллиметрового диапазона. Радар сообщает DSU на каком расстоянии от машины движется объект, с какой относительной скоростью и определяет его положение по горизонтали (левее, правее или по центру).

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

a) б)
Рис. 15. Активация круиза: a) попытка активировать без подмены данных радара; б) активация при подмене данных от радара.

Когда запускаем нашу обманку, на приборной панели загорается значок наличия впереди идущего автомобиля. Теперь мы можем тестировать наше управление. Запускаем команду на ускорение, и автомобиль начинает быстро ускоряться.

Как мы уже узнали, команда на ускорение и замедление одна. Поэтому тут же проверили и замедление. Поехали на на скорости с активным круиз-контролем, запустили команду на торможение, и авто сразу же замедлилось.

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

Что еще мы используем

Для создания беспилотника необходимо управление вспомогательными системами: поворотниками, стоп-сигналами, аварийной сигнализацией, клаксоном и пр. Всем этим так же можно управлять по CAN шине.

Оборудование и ПО

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

• Анализатор шины Marathon позволяет подключать и читать данные с двух шин одновременно. На сайте производителя анализатора есть бесплатное ПО для анализа логов. Но мы используем ПО, написанное в нашей компании для внутреннего пользования.
• Модуль StarLine Сигма 10 мы используем как платформу для работы с цифровыми интерфейсами. Модуль поддерживает CAN и LIN интерфейсы. При исследовании автомобиля пишем программы на C, зашиваем их в модуль и проверяем работу. Из модуля можем сделать сниффер трафика CAN-шины. Сниффер нам помогает понять, какие ID идут от блока или блокировать сообщения от штатных систем.
• Диагностическое оборудование Toyota/Lexus. С помощью этого оборудования можно найти команды управления системами автомобиля: поворотниками, стоп-сигналами, клаксоном, индикацией приборки.

Беспилотный автомобиль StarLine — это открытая площадка для объединения лучших инженерных умов России и мира с целью создания прогрессивных технологий беспилотного вождения, которые сделают наше будущее безопасным и комфортным.

Источник https://micromax.ru/solution/theory-practice/articles/2160/

Источник https://www.drive2.ru/l/461677786751305964/

Источник https://habr.com/ru/post/450140/