Controller Area Network
Парк автомобилей на наших улицах стремительно омолаживается и вместе с этим приходится осваивать и решать новые задачи связанные с диагностикой и ремонтом. Всё чаще и чаще сталкиваешься в своей повседневной работе с проблемами коммуникации между различными бортовыми системами автомобиля. Если ещё несколько лет назад приезжающие на диагностику автомобили с ошибками по CAN шине (первый символ в классификации диагностического кода неисправности — U) были редкими гостями, то сейчас это практически повседневная практика. Информация на эту тему в принципе доступна и её достаточно много, даже очень много — что с одной стороны хорошо, а с другой представляет собой определённую сложность в поиске необходимой информации. Этой статьёй хотелось бы в первую очередь дать общее представление о системе CAN (Controller Area Network) тем, кто только начинает с ней знакомство, и тем, кто желает в этом поглубже разобраться.
Что такое CAN?
Controller Area Network — это понятие вошло в обиход после того, как в начале 1980-х годов в Robert Bosch GmbH разработали стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Одно их первых внедрений в автомобильной промышленности было осуществлено на нескольких моделях автомобилей Mercedes-Benz в 1992 году. До этого момента электронное управление исполнительными функциями строилось по системе — один блок управления принимал электронные сигналы с различных датчиков и после их обработки посылал соответствующие команды на исполнительные устройства (такие как бензонасос, форсунки, катушки зажигания и прочие. ). Увеличение объёма функций управления автомобилем, передаваемое электронике, привело к появлению таких дополнительных систем как ABS, SRS, AT, Immobilaser и других. Совмещение этих функций в одном ЭБУ привело бы к его громоздкости и чрезмерной сложности, а так же к потере надёжности, когда выход из строя одной системы мог бы привести к потере управляемости всего автомобиля. Поэтому автопроизводители пошли по пути разделения функций управления и выделения всех систем в отдельные блоки. А для того, чтобы увязать все системы в единое целое для решения общих задач управления автомобилем, на помощь пришёл коммуникационный стандарт CAN от Robert Bosch GmbH и это всё шире и шире стало применяться в автомобилестроении. На сегодняшний день практически каждый новый автомобиль оснащён этой системой.
Всё в принципе просто и понятно, но как устроена CAN шина и на чём основывается принцип её работы? Вот один из примеров взаимосвязи электронных блоков управления и устройств завязанных в единую бортовую коммуникационную сеть автомобиля,- рис. 1
Здесь мы рассматриваем только блоки, связанные в проводную сеть, но в автомобилях 21 века находит всё большее применение и беспроводная передача информации. К примеру, система навигации, слежение за местонахождением автомобиля (защита от угона), контроль за давлением в шинах, удалённая диагностика и многие другие. В ближайшем будущем можно ожидать, что слияние воедино в бортовой сети автомобилей внутренних и внешних информационных потоков выведет управление транспортным средством на новый уровень безопасности и комфорта прежде всего в таких направлениях, как отображение информации предупреждения об опасных ситуациях на дорогах и даже активного смягчения последствий возможных столкновений автомобилей, а так же более рационального распределения транспортных потоков.
Немного предыстории — Взаимосвязь открытых систем (Open System Interconnection (OSI)).
Это очевидно, что если два или более микропроцессора взаимосвязаны в одну систему, то должен использоваться стандартный протокол который определяет, каким образом данные должны быть переданы между сетевыми блоками. Наиболее распространенным примером такого протокола является TCP/IP (Transmission Control Protocol / Internet Protocol), который используется для подключения хостингов в сети Интернет. Предшественником TCP/IP был протокол — Open System Interconnection (OSI). Этот протокол был разработан в 1982 году Международным бюро по стандартизации International Organization for Standardization (ISO 7498-1:1994 (E)). OSI протокол иногда называют как «семиуровневая» модель, поскольку он состоит из семи независимых элементов, которые определяют требования к взаимосвязи на различных уровнях взаимодействия.
Вот эти семь уровней:
1) Уровень приложений (Application Layer) — этот уровень определяет какие приложения (программы) имеют доступ к сети. Например — электронная почта, передача файлов, терминалы удалённого доступа и веб-браузеры.
2) Уровень представления данных (Presentation Layer) — этот уровень определяет такие моменты, как стандарты сжатия данных и их шифрования.
3) Уровень передачи данных (Transport Layer) — этот уровень обеспечивает стандарты передачи данных между адресатами, осуществляет контроль ошибок и безопасности.
4) Сетевой уровень (Network Layer) — этот уровень отвечает за вопросы маршрутизации сетевого трафика данных.
5) Уровень каналов связи (Data Link Layer) — этот уровень обеспечивает синхронизацию передачи данных и контроль ошибок.
6) Уровень контроля за сеансами связи (Session Layer) — этот уровень обеспечивает стандартизацию начала и завершения сеансов связи между различными приложениями и сетевыми блоками.
7) Физический уровень (Physical Layer) — этот уровень определяет стандарты физических характеристик устройств в сети, в том числе типы соединений и разъёмов, электрические характеристики кабелей, уровня напряжения, силы тока и тд.
Но задачи, решаемые протоколом OSI не в полной мере отвечали нуждам автомобильной электроники, и как следствие этого, инженерами Robert Bosch GmbH был разработан, в развитие протокола OSI, специальный протокол CAN, который определял стандарты физического и канального уровней модели OSI в кремнии для осуществления последовательной передачи информации между двумя или более устройствами.
Controller Area Network (CAN)
CAN был разработан Robert Bosch GmbH для автомобильной промышленности в начале 1980-х годов и официально публично выпущен в пользование в 1986 году. Эта разработка CAN от Bosch была принята в качестве стандарта ISO (ISO 11898), в 1993 переименована в CAN 2.0A, и расширена в 1995 году, чтобы позволить идентифицировать большее количество сетевых устройств в CAN 2.0B. Как правило, CAN шина соединяет в сеть модули (или узлы), используя два провода, витая пара. Многие компании и не только автомобильные, внедряют CAN протокол в свои разработки для взаимосвязи различных электронно-управляемых устройств. В неофициальной классификации устройства связанные протоколом CAN и имеющие процессоры серии MPC 5xx, называются TouCAN модули; имеющие процессоры серии MPC 55xx называются FlexCAN модули. CAN — последовательный, мульти-отправляющий, многоадресный протокол, это означает, что, когда шина свободна, любой узел, может отправить сообщение (мульти-отправляющее устройство), и все узлы могут получить и отреагировать на сообщение (многоадресно передано). Узел, который инициирует сообщение, называют передатчиком, любой узел не отправляющий сообщение называют получателем. Всем сообщениям присвоены статические приоритеты, передающий узел остаётся передатчиком до тех пор пока шина не станет неактивной или пока в сети не появилось сообщение от другого узла с более высоким приоритетом, процесс который определяет приоритет сообщений и называется — арбитраж. Сообщение по CAN шине может содержать до 8 байтов данных. Идентификатор сообщения описывает контент данных и используется получающими узлами для определения места назначения в сети (другими словами — адресата, узел которому это сообщение адресовано). В коротких сетях (≤ 40 м), скорость передачи сообщений может достигать до 1 Мбит/с. Более длинные сетевые расстояния уменьшают доступную скорость передачи, например до 125 Кбит/с в сети длиной до 500м. Высокоскоростной CAN (“High speed” CAN) сетью, считается сеть со скоростью передачи данных более 500 Кбит/с.
Основные принципы CAN
Детали спецификации CAN протокола полностью описаны в Robert Bosch GmbH, “CAN Specification 2.0,” 1991. Ознакомиться с документом в формате PDF можно по следующему адресу. Далее я дам максимально возможно краткое описание того как данные передаются по CAN, как структурированы сообщения CAN и как обрабатываются ошибки передачи сообщений.
Есть четыре типа сообщений CAN, или фреймы (frames): фрейм данных (Data Frame), удаленный фрейм (Remote Frame), ошибочный фрейм (Error Frame) и фрейм перегрузки (Overload Frame).
Data Frame — стандартное сообщение CAN, широковещательно передаваемые данные от передатчика на другие узлы сети.
Remote Frame — широковещательно передаваемое передатчиком сообщение, на запрос данных от конкретного узла сети.
Error Frame — может быть передан любым узлом, который обнаруживает ошибку в сети.
Overload Frame — используются как запрос на предоставление дополнительной паузы между получаемыми данными (Data Frame) или запросами на получение данных (Remote Frame).
Ниже проиллюстрированы различия между Data Frames для стандартов CAN 2.0A и CAN 2.0B,- рис. 2
Различие между форматами CAN 2.0А и CAN 2.0B заключаются в том что фрейм данных для CAN 2.0B поддерживает как стандартный идентификатор фрейма данных — 11 бит, так и расширенный идентификатор фрейма данных — о 29 бит. Фреймы стандартного и расширенного формата могут без проблем передаваться по одной на той же шине, и даже иметь в цифровой форме эквивалентный идентификатор.
В этом случае у стандартного фрейма будет более высокий приоритет,- рис. 3
Описание фрейма сообщения стандарта CAN 2.0А
Начало сообщения (Start of Frame (SOF)) — 1 бит, должен быть доминантным.
Идентификатор (Identifier) — 11 бит, уникальный идентификатор, указывает приоритет.
Удаленный запрос на передачу (Remote Transmission Request (RTR)) — 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения.
Резерв (Reserved) — 2 бита, должны быть доминантными.
Длина кода данных (Data Length Code (DLC)) — 4 бита, количество байтов данных (0-8).
Поле передаваемых данных (Data Field) — от 0 до 8 байт, размер определен в поле DLC.
Контрольный циклический избыточный код (Cyclic Redundancy Check (CRC)) — 15 бит.
Разделитель CRC — 1 бит, должен быть рецессивный.
Подтверждение (Acknowledge (ACK)) — 1 бит, передатчик отправляет рецессивный; получатель подтверждает доминантным.
Разделитель ACK — 1 бит, должен быть рецессивным.
Завершение сообщения (End of Frame (EOF)) — 7 бит, должны быть рецессивными,- рис. 4
Описание фрейма сообщения стандарта CAN 2.0В Начало сообщения (Start of Frame (SOF)) — 1 бит, должен быть доминантным.
Идентификатор стандартного и расширенного форматов (Identifier) — 11 бит, уникальный идентификатор, соответствует базовому ID в расширенном формате.
Идентификатор расширенного формата (Identifier – Extended Format) — 29 бит, состоит из 11 бит базового ID и 18 бит расширенного ID.
Удаленный запрос на передачу (Remote Transmission Request (RTR)) стандартный и расширенный форматы — 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения. В стандартном формате 11 бит идентификатора следуют за битом RTR.
Замещение удалённого запроса (Substitute Remote Request (SRR)). Для расширенного формата — 1 бит, должен быть рецессивный. SRR передаются в расширенных форматах сообщений на позиции бита RTR в стандартном сообщении. В арбитраже между стандартными и расширенными сообщениями, рецессивные SRR обеспечивает приоритет стандартным сообщениям.
Поле IDE – для стандартного и расширенного форматов — 1 бит, должен быть рецессивным для расширенного формата и доминантным для стандартного.
Резерв (Reserved r0) для стандартного формата — 1 бит, должен быть доминантным.
Резерв (Reserved r1, r0) для расширенного формата — 2 бита, должны быть рецессивными.
Длина кода данных (Data Length Code (DLC)) — 4 бита, количество байтов данных (0-8).
Поле передаваемых данных (Data Field) — от 0 до 8 байт, размер определен в поле DLC.
Контрольный циклический избыточный код (Cyclic Redundancy Check (CRC)) — 15 бит.
Разделитель CRC — 1 бит, должен быть рецессивный.
Подтверждение (Acknowledge (ACK)) — 1 бит, передатчик отправляет рецессивный; получатель подтверждает доминантным.
Разделитель ACK — 1 бит, должен быть рецессивным.
Завершение сообщения (End of Frame (EOF)) — 7 бит, должны быть рецессивными.
Фрейм данных CAN
Фрейм данных CAN состоит из семи полей: Начало фрейма (SOF), арбитраж, управление, данные, цикличные, проверка по избыточности (CRC), подтверждение (ACK) и конец фрейма (EOF). Биты сообщения CAN обозначены как «доминирующие» (0) или «рецессивные» (1). Поле SOF состоит из одного доминирующего бита. Все сетевые узлы синхронно ожидают команды разрешения на передачу сообщений и начинают передавать одновременно. Арбитражная схема определяет, какой из узлов, пытающихся передавать сообщения имеет главный приоритет и фактически будет управлять шиной.
Арбитраж (Arbitration)
Арбитражное поле сообщения CAN состоит из 11-или 29-разрядного идентификатора и бита удаленной передачи (RTR). Арбитражную схему CAN называют “носителем контроля с множественным доступом и обнаружением коллизий” или CSMA/CD, которая гарантирует, что самое важное сообщение с наивысшим приоритетом будет передано по всей сети в первую очередь. Приоритет сообщения определен численным значением идентификатора в арбитражном поле, поле с самым низким численным значением имеет самый высокий приоритет. Неразрушающий, интеллектуальный арбитраж разрешает конфликты среди конкурирующих передатчиков. Это означает, что шина может считаться действующей как логический элемент И (AND gate). Если какой-либо узел пишет по сети доминантный признак (0), то каждый узел читает доминирующий бит независимо от его назначения, заданного передающим узлом. Каждый передающий узел всегда читает ответ на каждый переданный бит. Если узел передает рецессивный бит запроса на отправку сообщения и получает доминирующий бит для прочтения сообщения, он сразу же прекращает передавать.
Ниже проиллюстрирован приоритет сетевого арбитража где третий узел имеет высший приоритет и первый низший,- рис. 5
Бит RTR включён для того чтобы различать сообщения для передачи и удаленные запросы на приём сообщений. В стандартных сообщениях для передачи (Data Frame) бит RTR должен быть доминантным, а в удаленных запросах на приём сообщений (Remote Frame) должен быть быть рецессивным.
Контрольное поле и поле данных в сообщении (Control and Data Fields)
Поле управляющее длиной кода данных (DLC) состоит из 6 бит (из которых используются только 4 младших бита), они показывают количество данных в сообщении. Поскольку только до 8 байт данных может быть отправлено в одном сообщение, поле DLC может принимать значения в диапазоне от 000000 до 000111. Данные которые должны быть переданы содержатся только в поле данных. В первую очередь передается наиболее значимый байт (Most significant byte (MSB)) из байтов данных.
Обработка ошибок (Error Handling)
В протоколе CAN реализовано пять уровней обнаружения ошибок. На уровне сообщений, выполняется циклическая проверка избыточности (Cyclic Redundancy Check (CRC)), проверки сообщения и обязательное подтверждение проверок (Acknowledge (ACK)). Бит проверки уровней состоит из монитора и наполнения.
Циклические ошибки избыточности обнаруживаются, используя код CRC размером 15 битов, вычисленный передатчиком из контента сообщения. Каждый получатель, принимающий сообщение, повторно вычисляет код CRC и сравнивает его с переданным значением. Несоответствие между этими двумя вычислениями заставляет установить флаг (flag) ошибки. Проверяемые сообщения, в которых будет установлен флаг ошибки, это обнаружение получателем недопустимого бита в разделителе CRC, разделителе ACK, в завершении сообщения EOF или в 3-х битном разделяющим сообщения пространстве. В конечном итоге каждый принимающий узел записывает доминантный бит в ячейку разделителя ACK, которая затем читается отправившим это сообщение узлом. И если приём сообщения получателем не подтверждён (возможно потому что получающий узел перестал работать) то устанавливается флаг ошибки подтверждения (ACK).
На уровне битов мы уже отметили, что каждый переданный бит считывается снова передатчиком этого сообщения при контроле подтверждения о получении сообщения, присланного получателем. Если контролируемое значение отличается от отправленного, значит на уровне битов обнаружена ошибка. Дополнительно, ошибки на уровне битов обнаруживаются при помощи «вставок»: После пяти последовательных идентичных битов, которые передаются в сообщении следует «вставка», бит противоположной полярности вставляется передатчиком в поток передаваемых битов (биты «вставки» вставляются в сообщение от поля SOF до поля CRC). Получатели автоматически проверяют сообщение на наличие «вставок». Если любой из принимающих узлов сети обнаруживает в полученном сообщении шесть последовательных идентичных битов, то фиксируется ошибка (отсутствия «вставки»). В дополнение для обнаружения ошибок, «вставки» гарантируют, что есть достаточно не нулевых окончаний в потоке битов (non-return to zero (NRZ)), чтобы поддержать синхронизацию.
Сообщение об ошибке (The CAN Error Frame)
Если передающий или принимающий узел обнаруживает ошибку, он немедленно прерывает приём или передачу текущего сообщения. Сообщение об ошибке называемое «флаг» ошибки, составляется из шести доминантных битов и разделителя сообщения об ошибке состоящего из восьми рецессивных битов. Так как эта строка битов нарушает правило «вставок», все другие узлы также передают сообщение об ошибке. После критичного количества обнаруженных ошибок, узел в конце концов само-отключается. Надежность, особенно в производстве и автомобильной электронике, где применяется технология CAN, требует, чтобы сеть могла отделять случайные ошибки (из-за скачков напряжения, шумов или других временных причин) от постоянных, являющихся причиной неисправности узла из-за дефектов в оборудовании. Следовательно, узлы хранят и отслеживают число обнаруженных ошибок. Узел может быть в одном из трех режимов в зависимости от количества зафиксированных ошибок:
Если количество зафиксированных ошибок в каждом буфере передачи или приёма соответствующего узла, больше чем нуль и меньше чем 128, узел считается «активным с ошибкой» (“error active”), указывая на то, что несмотря что узел остается полностью функциональным, по крайней мере одна ошибка была обнаружена.
Если количество зафиксированных ошибок между 128 и 255, то узел переходит в «пассивный с ошибками» (“error passive”) режим. В «пассивном с ошибками» режиме узел будет передавать на более медленном уровне, отправляя 8 рецессивных битов прежде чем снова отправить сообщение, распознав что шина свободна.
Если количество зафиксированных ошибок более 255, то узел переходит в режим «отключен от сети» (“busoff”), отключив себя самостоятельно.
Ошибка при получении добавляет в общее количество учтённых ошибок 1, ошибка при передаче добавляет в общее количество учтённых ошибок 8. Последующие безошибочные сообщения постепенно уменьшают количество учтённых ошибок на 1, за каждое безошибочное сообщение. Если общее количество учтённых ошибок возвращается к нулю, узел возвращается в нормальный режим функционирования. Узел в находящийся режиме “busoff” может перейти в режим “error active” после 128 входов в сеть из 11 последовательных рецессивных битов, которые были проконтролированы. Сообщение считается безошибочным, если передающий узел не нашёл в нём ошибок вплоть до поля EOF. Повреждённые сообщения отсылаются повторно сразу как только шина становится свободной.
Запрос данных от конкретного узла сети (The CAN Remote Frame)
Узел, которому необходимы данные от другого узла сети, может запросить передачу таких данных, отправив соответствующий запрос на получение данных (Remote Frame). Например, микропроцессору управления центральным замком на вашем автомобиле необходимо знать положение селектора коробки передач от ЭБУ трансмиссии (является ли он в положении «паркинг»). Структура запроса на получение данных аналогична структуре стандартного сообщения только без поля данных (data field) и с рецессивным RTR битом.
Запрос на предоставление дополнительной паузы между получаемыми данными и свободное пространство между сообщениями (Overload Frames and Interframe Space)
Если какой-либо узел сети будет получать сообщения быстрее, чем он может их обработать, то будет сгенерирован запрос на предоставление дополнительной паузы между получаемыми данными (Overload Frames) чтобы обеспечить дополнительное время между принимаемыми данными или запросами на получение сообщений (Remote Frame). Подобно сообщению об ошибке, Overload Frame имеет два поля с битами: flag перегрузки состоящий из шести доминирующих битов и разделитель перегрузки, состоящий из восьми рецессивных битов. В отличие от сообщений об ошибке, суммарный подсчёт Overload Frames не ведётся.
Пространство между сообщениями состоит из трех рецессивных битов так же, как и время простоя шины между сообщениями или удаленными запросами на передачу. Во время перерыва никакому узлу не разрешают инициировать передачу (если доминирующий бит будет обнаружен во время Перерыва, то Overload Frame будет сгенерирован). Время простоя шины длится, пока у узла нет чего-то для передачи, а когда начинается передача, то в этот момент появление доминирующего бита на шине сигнализирует о начале передачи сообщения SOF.
Загрузка шины (Bus Loading)
CAN обеспечивает устойчивое, простое и гибкое сетевое решение для производственных, автомобильных и многих других приложений. Главный недостаток протокола CAN — что задержка сообщения не является определённой (из-за существования Error Frames, Overload Frames и повторных передач), и увеличения задержки ведёт к увеличению сетевого трафика. В целом использование шины не должно превышать 30% от максимальной мощности шины и гарантировать, что низкоприоритетные сообщения не испытывают недопустимую задержку. Использование шины определено как деление двух величин — общее количество использованных для передачи битов поделённое на общее максимально доступное количество для передачи битов , и вычисляется следующим образом:
Шаг 1 — Выбирается единица времени ≥ самого медленное зафиксированного периодического сообщение в сети (обычно 1 секунда).
Шаг 2 — Определяются все периодические сообщения.
Шаг 3 — К каждому из этих сообщений приблизительно одинакового размера, добавляются 47 служебных бит (размер служебных полей данных — SOF + Arbitration + RTR + Control + CRC + Acknowledgment + EOF +
Interframe Space = 1 + 11 + 1 + 6 + 16 + 2 + 7 + 3 = 47 bits).
Шаг 4 — Рассчитывается количество бит используемых в сообщениях путем умножения размера сообщения в битах на количество передач выполняемых в единицу времени.
Шаг 5 — Суммирование всех битов используемых в переданных сообщениях для оценки общего объёма сетевого трафика. Умножение этой величины на страховочный коэффициент 1.1 для получения наихудшего прогноза сетевого трафика.
Шаг 6 — В завершении, поделите общее количество использованных для передачи битов на общее максимально доступное количество для передачи битов (например, 125 Кбит/с или 500 Кбит/с умножаются на единицу времени) для получения предполагаемого процента загрузки шины,- рис. 6
Протоколы синхронизированные по времени (Time-triggered Protocols)
Для контроля над сетью в реальном времени было бы желательно реализовать такой протокол связи, который гарантирует, что для сообщений выбираются крайние временные параметры независимо от нагрузки на шину. Пример такого протокола, который контролирует временной уровень связи CAN данных, это “time-triggered CAN,” или TTCAN (ISO 11898-4). TTCAN сообщения имеют два специальных типа, называемые «окна времени» (time windows): привилегированные окна времени (exclusive time windows), и арбитражные окна времени (arbitrating time windows). Еxclusive time windows прикреплены к специальным сообщениям, которые передаются периодически. Таким образом, Еxclusive time windows не конкурируют за доступ к шине. Аrbitrating time windows используются для сообщений не имеющих строгих ограничений по времени.
Аrbitrating time windows, как нормальные сообщения CAN, конкурируют за доступ к шине на основе приоритета через арбитраж. Тime-triggered CAN протокол, требует наличия в сети «главного узла» (master node), который периодически широковещательно передает сигнал времени сети (называемый глобальным временем (global time)) в специальном информационном сообщении. Для повышения отказоустойчивости в сети должны быть несколько потенциальных главных узлов. Если главный узел перестал работать (обнаружено отсутствие специального информационного сообщения), другие потенциальные главные узлы конкурируют за статус «главного узла» при помощи арбитража и новым «главным узлом» становится узел с самым высоким приоритетом. После этого новый главный узел начинает широковещательно передавать специальные информационные сообщения — global time. Тime-triggered CAN протокол не ретранслирует повреждённые сообщения, и при этом это не вызывает Error Frames.
У протокола TTCAN есть конкурирующий протокол FlexRay, разработанный консорциумом автомобильных производителей и поставщиков. Коммуникационное сообщение (фрейм) FlexRay состоит из периодических синициированных «статических» и «динамических» частей. Статический сегмент составлен из одинаковой длины временных интервалов, соответствующих соединенным в сеть узлам. Каждый узел передает свои сообщения синхронно в его зарезервированном слоте. Статический сегмент также передает «синхронизирующий» кадр, чтобы обеспечить глобальную переменную (timebase) для сети. В отличие от CAN, нет никакого арбитража для шины. Динамический сегмент — по существу механизм «опроса» где каждому узлу дают возможность поместить инициированное событие или асинхронное сообщение в шину в порядке приоритетов, используя механизм синхронизации «миниразделения на слоты». Для повышения отказоустойчивости, узлы сети использующей протокол FlexRay, могут быть связаны двумя шинами или каналами одновременно.
Ну вот, в принципе, вся основная информация о протоколе CAN, а теперь немного о том, как выглядит CAN шина на примере автомобилей произведённых в Японии. Сразу хочу отметить, что без надлежащего диагностического оборудования проводить диагностику и ремонт неисправностей CAN шины можно в очень ограниченном диапазоне. Всё сведётся к проверке физической целостности проводов, проверки состояния соединительных разъёмов, проверки сопротивления проводки и Terminal resistor, проверки соответствующего уровня напряжения на CANlow и CANhigh линиях. Применение в диагностике дилерского оборудования тоже лишь облегчит проверку и сузит круг поиска неисправности, с очень большой неохотой автопроизводители допускают контакт с программным обеспечением, своей интеллектуальной собственностью. В случае проблем на программном уровне возможно только перепрограммирование или замена соответствующего ЭБУ.
Пример CAN шины автомобиля Nissan 2007г.в. — Рис. 7
Интерфейс программы Consult III (Nissan), окно диагностики CAN шины,- рис. 8
Пример CAN шины автомобиля Mitsubishi 2004г.в. – рис. 9
Пример CAN шины автомобиля Mazda 2004г.в. – рис. 10
Пример CAN шины автомобиля Toyota 2007г.в. – рис. 11
За дополнительной и полной информацией по системе каждого диагностируемого автомобиля следует обращаться к соответствующим документам автопроизводителей (WSM и TSB).
Удачных всем ремонтов и беспроблемного обслуживания своих автомобилей.
Задать вопрос или обсудить статью вы можете на форуме Легион-Автодата (нажать)
Боровиков Игорь Александрович
© Легион-Автодата
(ник на форуме Легион-Автодата – semirek)
СОЮЗ АВТОМОБИЛЬНЫХ ДИАГНОСТОВ
CAN против RS 485: почему тенденция направлена в сторону CAN
В отличие от предыдущих стандартов физического уровня, в частности RS‑423, RS‑422 и RS‑232, появление RS‑485 стало поистине эволюционным этапом. Системы связи с поддержкой данного стандарта представляют собой многоточечную систему и имеют до 32 узлов в одиночной системе (с репитерами до 256).
Примерно в то же время, когда создавались упомянутые выше интерфейсы, используемые в таких приложениях, как компьютерные клавиатуры и мыши, принтеры и оборудование для промышленной автоматизации, интерфейс CANbus проектировался как автомобильная коммуникационная платформа, предложенная Робертом Бошем (Robert Bosch), владельцем компании Robert Bosch GmbH, для снижения стоимости производства авто. Эта шина стала альтернативой традиционным толстым многожильным автомобильным кабелям и упростила их прокладку благодаря применению многоузловых шин. Впервые представленный в модели BMW‑850 в 1986 году, автомобильный CAN-интерфейс сэкономил в ней более 2 км различных проводов! Кроме того, было значительно сокращено количество разъемов, а оценочная экономия веса машины составила 50 кг [1] . Так сложилось, что RS‑485 был предназначен для нужд промышленного рынка, а CAN — для автомобильного и транспортного сегмента, но постепенно он нашел место и в приложениях, скажем так, вне своей юрисдикции, то есть в автомобильной и аэрокосмической отраслях.
Благодаря своей высокой устойчивости при эксплуатации в непростых условиях, характерных для автомобильных приложений, возможностям защиты от сбоев и уникальной обработке сообщений CANbus теперь используется там, где прежде никогда не был распространен. Нынешние рыночные тенденции демонстрируют все более широкое внедрение CANbus, порой заменяющего RS‑485 в традиционных индустриальных программах.
Согласно рыночным отчетам, применение CANbus увеличивается в разы, что является исключительным фактом для рынка интерфейсов. И хотя отчеты не разделяют промышленные и автомобильные рынки, многие согласны с тем, что промышленные рынки составляют около 20–30% от общего объема выпускаемой продукции. Рост использования интерфейсов в автомобильной промышленности можно объяснить распространением электроники, установленной сегодня в автомобилях. Современные автомобили имеют сложные микропроцессорные системы, необходимые для таких функций, как резервные камеры, автоматическая парковка, информационно-развлекательные системы, распознавание слепых зон и многое другое. Появление данных подсистем связано с увеличением числа датчиков и микроконтроллеров в авто, требующихся для обработки информации от всех сложных систем, действующих внутри машины. Еще в 1990‑х годах многие автопроизводители начали переход от ручного переключения передач к автоматическим, а позже и к коробкам передач с электронным управлением, основанным на поступающих на микроконтроллер данных о скорости, положении дроссельной заслонки и информации от барометрических датчиков. Сегодня на одном транспортном средстве можно насчитать свыше 100 датчиков и микроконтроллеров, многие из которых общаются по шине CAN. Даже полностью электрический автомобиль Tesla S имеет внутри 65 микроконтроллеров [2].
На индустриальном рынке также наблюдается рост внедрения интерфейса CAN. Промышленные CAN-приложения имеют достаточно широкий охват и устанавливаются в самых разнообразных приложениях — от коммерческих беспилотных летательных аппаратов (дронов) до элементов управления лифтом и даже газонокосилками коммерческого назначения. Поставщики микросхем признают этот факт и разрабатывают продукты для удовлетворения все возрастающей потребности в CAN вне традиционного рынка автомобильной промышленности. Другой фактор, способствующий увеличению применения CAN в индустриальной сфере, — это переход многих инженеров‑автомобилестроителей в промышленный сегмент, где они, естественно, применили свой опыт работы с шиной CAN и ее уникальные преимущества. Еще одна причина внедрения интерфейса CAN на промышленном рынке связана с присущей ему отказоустойчивостью и способностью эффективно обрабатывать кадры сообщений на многоузловой шине.
Для того чтобы объяснить преимущества CAN по отношению к RS‑485, лучше всего оценить сходства и различия между двумя стандартами — ISO 11898-2-2016 [3] и TIA/EIA‑485 (сейчас действует ANSI TIA/EIA‑485‑A ) соответственно. Оба стандарта определяют уровни приемопередатчиков, которые представлены на диаграмме (рис. 1) для стороны передачи.
Оба протокола имеют дифференциальный выходной сигнал. Выход RS‑485 представляет собой классический дифференциальный сигнал, в котором один сигнал является инвертированным, или зеркальным отражением другого. Выход A — неинвертирующая линия, а выход B — инвертирующая линия. Дифференциальный диапазон +1,5…+5 В равен логической 1 или значению, а пределы –1,5…–5 В — логическому 0 или пробелу. Сигнал с уровнем, лежащим в диапазоне –1,5…+1,5 В, считается как неопределенный. Важно отметить, что когда RS‑485 не используется, то его выход пребывает в состоянии высокого импеданса.
У шины CAN выходной дифференциальный сигнал несколько иной. Так, здесь предусмотрено два выхода в виде CANH- и CANL-линий данных, которые являются отражением друг друга (рис. 1) и представляют собой инвертированную логику. В доминирующем состоянии (бит нуля, используемый для указания приоритета сообщения) CANH-CANL определяются как 0, когда напряжение на них составляет +1,5…+3 В. В рецессивном состоянии (1 бит и состоянии незанятой шины) сигнал драйвера определяется как логическая 1, когда дифференциальное напряжение находится в диапазоне –120…+12 мВ или в приближении к нулю.
Рис. 1. Сравнение допустимых уровней выходных дифференциальных сигналов драйверов RS 485 и CAN
Для стороны приемника стандарт RS‑485 определяет входной дифференциальный сигнал, когда он находится в пределах ±200 мВ…+5 В. Для CAN входной дифференциальный сигнал составляет +900 мВ…+3 В, а рецессивный режим находится в диапазоне –120…+500 мВ. Когда шина пребывает в режиме ожидания или когда не загружена и трансивер находится в рецессивном состоянии, напряжения на линиях CANH и CANL должны быть в рамках 2–3 В.
Как RS‑485, так и CAN имеют необходимый технологический запас по уровням распознавания для работы в приложениях, в которых сигнал может быть ослаблен из-за характеристик и качества используемого кабеля (экранированного или неэкранированного) и длины кабелей, что может сказаться на емкости подключения системы. Для сравнения допустимых уровней входных дифференциальных сигналов со стороны приемника RS‑485 и CAN следует обратиться к рис. 2.
Рис. 2. Сравнение допустимых уровней входных дифференциальных сигналов для RS 485 и CAN со стороны приемника
Кроме того, оба стандарта имеют нагрузочные согласующие резисторы с одинаковым значением 120 Ом, устанавливаемые на концах линии. Эти резисторы необходимы, чтобы обеспечить согласование линии связи по волновому сопротивлению линии передачи и тем самым избежать отражения сигнала. Другие технические характеристики, такие как скорость передачи данных и количество допустимых узлов, носят информационный характер, а не являются строгими требованиями, подлежащими обязательному выполнению. Для удовлетворения нужд рынка большинство выпускаемых RS‑485- и CAN-трансиверов превышает стандартную скорость передачи данных и допустимое количество узлов. Например, интегральный полудуплексный трансивер RS‑485 индустриального класса из микросхемы MAX22500E [4] от компании Maxim достиг скорости в 100 Мбит/с. А новый стандарт CAN-FD, ISO 11898-2:2016, хотя и определяет временные характеристики для скоростей 2 и 5 Мбит/с, но не ограничивает скорость передачи данных значением 5 Мбит/с. CAN-трансиверы превысят требования своего стандарта так же, как и приемопередатчики RS‑485. Что касается устойчивости к синфазному сигналу, параметр CMR (Common-Mode Range, диапазон синфазных напряжений) для RS‑485 составляет –7…+12 В и для CAN –2…+7 В.
Однако многим приложениям требуется более высокая производительность в части CMR, что относится к обоим типам рассматриваемых интерфейсов. Это связано с тем, что они в основном используются для многоузловых шин, а их узлы могут иметь источники питания с разными силовыми трансформаторами или кабели находиться в непосредственной близости к оборудованию с достаточно мощными переменными электромагнитными полями, способными повлиять на заземление между узлами системы. Таким образом, учитывая множество самых различных приложений, работающих в жестких условиях индустриальной среды, часто требуется более высокая устойчивость CMR, выходящая за пределы стандартных уровней –7…+12 В.
Для решения этой проблемы существуют приемопередатчики RS‑485 и CAN нового поколения, которые имеют значительно более широкий диапазон устойчивости к воздействию синфазной помехи, а именно до ±25 В. На диаграмме, приведенной на рис. 3, представлен флуктуирующий диапазон синфазного сигнала для приемопередатчика RS‑485. Несмотря на то, что сигнал синфазного напряжения растет вверх и вниз, пока уровень синфазного напряжения (VCM) находится в пределах допустимого диапазона, он не влияет на дифференциальный сигнал шины и приемник способен принимать и распознавать сигнал на линии без ошибок. Диаграмма на рис. 3 показывает допустимый диапазон изменения синфазного сигнала для RS‑485.
Рис. 3. Пояснение параметра CMR на примере трансивера RS 485
Еще одна особенность, присущая как приемопередатчикам CAN, так и RS‑485, — защита от сбоев. Устройства с защитой от ошибок имеют внутреннюю цепь защиты от воздействия повышенного напряжения на выходы драйвера входа приемника. Это необходимо, чтобы уберечь устройства от случайных коротких замыканий между локальным источником питания и линиями передачи. В данном направлении микросхемы компании Maxim занимают лидирующее положение в отрасли. Они, как, например, широко используемая и в настоящее время MAX13041, гарантируют уровни защиты от сбоев до ±80 В и даже с некоторым дополнительным запасом до полного пробоя и выхода цепи защиты из строя [5]. Причем важно то, что этот уровень защиты гарантируется независимо от того, подано питание на трансивер или он обесточен.
Среди основных причин того, почему в индустриальных приложениях предпочтение отдается CAN-, а не RS‑485‑трансиверам, следует назвать и способ обработки сообщений на шине. В мультиузловой системе, используемой для общения с микропроцессором RS‑485, могут быть случаи, когда несколько сообщений отправляются одновременно. Что иногда приводит к коллизиям, иначе известным как конкуренция. Если подобное происходит, состояние шины может оказаться неверным или неопределенным, что вызовет ошибки данных. Кроме того, такая конкуренция может повредить или ухудшить параметры производительности, когда несколько трансиверов RS‑485 на шине находятся в одном, а один приемопередатчик — в противоположном состоянии. Тогда от одиночного передатчика RS‑485 может потребоваться довольно значительный ток, который, вероятно, вызовет отключение микросхемы из-за превышения максимально допустимой температуры или даже приведет к необратимому повреждению системы. Здесь CANbus по сравнению с протоколом RS‑485 имеет большое преимущество. С помощью CANbus удается разрешить проблему передачи нескольких сообщений на линии путем ранжирования каждого из них.
Рис. 4. Формат кадра передачи данных CAN
Перед тем как приступить к работе по проектированию системы, инженеры назначают разные уровни задач. Ранее упоминалось, что CAN имеет доминантное и рецессивное состояние. Во время передачи сообщение с более высоким назначенным доминантным состоянием «выигрывает» конкуренцию и будет продолжать передачу, в то время как другие узлы с более низким приоритетом будут видеть доминирующий бит и прекратят передавать данные. Этот метод называется арбитражем, где сообщения приоритетны и принимаются в порядке их статуса. Узел, который проигрывает в результате более низкого назначенного приоритета, повторно отправит свое сообщение, когда его уровень окажется доминирующим. Это продолжается для всех узлов, пока они не выполнят передачу. На рис. 4 более подробно рассмотрен формат кадра данных сообщения в протоколе CAN. Эта временная диаграмма и таблица 1 наглядно демонстрируют, где и как происходит арбитраж.
Краткий обзор протокола 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.