Can protocol описание

Обновлено: 10.01.2025

Промышленная сеть CAN (Controller Area Network) была создана в конце 80-х годов фирмой Bosch как решение для распределенных систем, работающих в режиме реального времени. Первая реализация CAN применялась в автомобильной электронике, однако сейчас CAN находит применение практически в любых типах машин и промышленных установок, от простейших бытовых приборов до систем управления ускорителями элементарных частиц. В настоящий момент CAN-протокол стандартизован в международном стандарте ISO 11898.

Основные положения стандарта CAN.

CAN контроллеры.
Протокол CAN полностью реализован аппаратно - в виде микросхем- CAN контроллеров или в виде стандартного периферийного устройства в составе микросхемы- микроконтроллера. Все производители современных микроконтроллеров по крайней мере в одном из семейств имеют микроконтроллеры со встроенным периферийным одним или несколькими CAN-контроллерами. Таким образом, сегодня, СAN-контроллер является таким же стандартным периферийным устройством как контроллер SPI, I2C или UART.

Протоколы высокого уровня (HLP).
Протокол CAN описывает только то, как пакеты должны быть доставлены от одного узла сети к другому. CAN ничего не говорит о том, как нужно интерпретировать поле данных пакета, как использовать поле арбитража (идентификатор), как обеспечить передачу данных, длина которых превышает 8 байт, какую логическую схему передачи должны использовать общающиеся между собой узлы и т.п. Другими словами CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI. Положения, которые не специфицируются стандартом CAN, (верхние пять уровней модели ISO/OSI) описываются, так называемыми CAN протоколами высокого уровня (HLP - Higher Layer Protocols). В настоящий момент существует несколько HLP протоколов. Они описывают следующие общие положения:

В грузовом автотранспорте, тракторах, сельскохозяйтсвенных и лесных машинах используют семейство протоколов SAE J1939 . В легковых автомашинах применяются "закрытые" протоколы производителей стандартизованные только на уровне подключения некоторых диагностических приборов и основанные идеологически на семействе протоколов SAE J1939.
Для построения децентрализованных встроенных систем реального времени (embedded network) используют протокол CANopen .
Для решения задачи АСУ ТП с использованием сети СAN-bus применяют протокол DeviceNet .
Для применения в аэрокосмической области все болшее признание полчает протокол ARINC 825 .

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

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

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

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

Протокол CAN

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

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

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

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

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

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

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

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

Продукты CAN

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

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

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

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

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

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

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

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

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

Кадр данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Кадр ошибки содержит флаг ошибки (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 – относится к оргинальной спецификации и её ревизиям.

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

Основной 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 и наоборот. Проблемы с совместимостью отсутствуют.

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

Мы говорили, что идентификатору доступны 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:

Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна 🙂 Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:

Скорость	Длина линии
1 Мбит/с	50 м
500 кбит/с	100 м
125 кбит/с	500 м
10 кбит/с	5 км

Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:

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

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

С этим вроде бы разобрались, давайте двигаться дальше!

Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:

Кадр данных (data frame)
Кадр удаленного запроса (remote frame)
Кадр перегрузки (overload frame)
Кадр ошибки (error frame)

А это структура расширенного:

Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.

Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.

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

И на этом еще не все! Каждый узел может находиться в одном из трех состояний:

Error Active
Error Passive
Bus Off

Счетчик ошибок передачи
Счетчик ошибок приема

Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.

Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:

Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании 🙂

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

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

Разъемы CAN

Для разъемов CAN стандартов не существует! Обычно, каждый (!) протокол более высокого уровня (Higher Layer Protocol) описывает один или несколько предпочтительных типов разъемов. Основные типы:

• 9–контактный DSUB, предложен CiA;

• 5–контактный Mini–C и/или Micro–C, используется DeviceNet и SDS;

• 6–контактный Deutsch разъем, предложенный CANHUG для транспортных гидравлических систем.

Разъемы CAN

Данное назначение контактов разъема рекомендовано CiA и фактически является промышленным стандартом.

1	-	Резерв
2	CAN_L	Линия шины CAN_L (доминантная низкая)
3	CAN_GND	Заземление CAN
4	-	Резерв
5	(CAN_SHLD)	Опционально: экран CAN
6	(GND)	Опционально: заземление CAN
7	CAN_H	Линия шины CAN_H (доминантная высокая)
8	-	Резерв (линия ошибок)
9	CAN_V+	Опционально: питание

Для пользователей продукции KVASER: Пожалуйста заметьте, что специфическое употребление этих контактов в кабелях KVASER DRVcan описано в документе LAPcan Hardware Guide, который можно скачать на сайте компании.

Нумерация контактов действительна для разъема типа «папа„, при взгляде со стороны разъема, или для разъема типа “мама», при взгляде со стороны распайки. – Чтобы запомнить расположение контактов, заметьте, что контакт CAN_LOW имеет МЕНЬШИЙ (LOW) номер, а CAN_HIGH – БОЛЬШИЙ (HIGH).

5-контактный Mini–C

Используется как DeviceNet , так и SDS , и является совместимым для этих двух протоколов.

Контакт	Функция	Цвет DeviceNet
1	Экран	Неизолированный
2	V+	Красный
3	V-	Черный
4	CAN_H	Белый
5	CAN_L	Синий

Модули оснащены разъемами типа «папа». Подаваемое напряжение 24 В ±1%

6-контактный Deutsch DT04-6P

Рекомендован CANHUG для использования в транспортных гидравлических системах

Разъемы на модулях типа «папа», разъемы шины – «мама». На данный момент нет никаких рекомендаций по вопросу подачи питания.

Тактовая синхронизация CAN

Схема бита

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

Схема бита данных шины CAN:

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

Сегмент воспроизведения нужен для компенсации задержки на линиях шины.

Сегменты фазы могут быть сокращены (сегмент фазы 1) или удлинены (сегмент фазы 2), если это потребуется для сохранения синхронизованности тактовых частот.

Уровни шины замеряются на границе между сегментом фазы 1 и сегментом фазы 2.

Большинство контроллеров CAN также обеспечивают возможность трехкратного замера на протяжении одного бита. В таком случае, замер происходит на границах двух квантов, предшествующих точке замера и результат зависит от мажоритарного декодирования (это верно как минимум в случае 82527).

Тактовая синхронизация

Для того, чтобы регулировать встроенный в чип генератор тактовых частот шины, контроллер CAN может сократить или удлинить бит на целое число квантов. Максимальное количество таких временных поправок бита определяется параметром «ширина скачка синхронизации» (Synchronization Jump Width, SJW).

Жесткая синхронизация происходит при переходе стартового бита от рецессивного к доминантному. Отсчет времени прохождения бита начинается заново с этой границы.

Вычисление регистра тактовой синхронизации

Большинство контроллеров CAN позволяют программисту осуществлять настройку тактовой синхронизации используя следующие параметры:

• Значение предварительного делителя тактовой частоты

• Количество квантов перед точкой замера

• Количество квантов после точки замера

• Количество квантов в «ширина скачка синхронизации» (Synchronization Jump Width, SJW)

Обычно для этих целей выделяется два регистра: btr0 и btr1. Однако они могут слегка различаться у разных контроллеров, поэтому внимательно читайте инструкцию.

В контроллерах 82c200 и SJA1000, производства NXP (ранее Philips), раскладка регистра выглядит приблизительно так:

	7	6	5	4	3	2	1	0
btr0	SJW1	SJW0	BRP5	BRP4	BRP3	BRP2	BRP1	BRP0
btr1	SAM	TSEG22	TSEG21	TSEG20	TSEG13	TSEG12	TSEG11	TSEG10

• BRP0..BRP5 устанавливают значение предварительного делителя тактовой частоты

• SJW0..SJW1 устанавливают длину SJW

• TSEG10..TSEG13 устанавливают количество квантов перед точкой замера (стартовый бит не включен)

• TSEG20..TSEG22 устанавливают количество квантов после точки замера

• SAM при установке значения 1 производится три замера, при установке значения 0 – один замер

Примечание: реальные значения этих параметров несколько отличаются от значений, вписанных в регистр.

Пример: если сигнал генератора, подаваемый на SJA1000, имеет частоту 16 МГц, и мы желаем получить скорость передачи 250 кбит/с, с точкой замера в районе 62% всего бита, и SJW равным 2 квантам, мы можем установить –
BRP = 4, что дает продолжительность кванта 2 × 4 / 16000000 с = 500 нс, и

TSEG1 = 5, что дает 5 квантов перед точкой замера, и

TSEG2 = 3, что дает 3 кванта после точки замера.

Каждый бит будет содержать 5 + 3 = 8 квантов, что даст нам желаемую скорость передачи 1 / (8 × 500 нс) = 250 кбит/с. Значения регистра должны быть следующими:

Точка замера в районе 5/8 = 62.5% бита.

Обработка ошибок CAN

Как CAN обрабатывает ошибки

Каждый узел обслуживается двумя счетчиками ошибок: счетчиком ошибок передачи (Transmit Error Counter) и счетчиком ошибок приёма (Receive Error Counter). Существуют правила, регламентирующие повышение и/или понижение значения этих счетчиков. По существу, передатчик определяет повышение числа сбоев в счетчике ошибок передачи быстрее, нежели слушающие узлы увеличат значения своих счетчиков ошибок передачи. Это потому, что есть немалая вероятность, что сбой именно в передатчике! Когда значение любого счетчика ошибок превышает определенную величину, узел сначала становится Error Passive – это значит, что он не будет активно разрушать трафик шины при обнаружении ошибки; а затем Bus Off – это значит, что узел вообще не будет принимать участия в передаче данных по шине.

При помощи счетчиков ошибок узел CAN может не только обнаруживать сбои, но и ограничивать ошибки.

Механизмы обнаружения ошибок

1.Мониторинг битов (Bit Monitoring).

2.Вставка битов (Bit Stuffing).

3.Проверка кадра (Frame Check).

4.Проверка распознавания (Acknowledgement Check).

5.Проверка циклической избыточности (Cyclic Redundancy Check).

Мониторинг бита

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

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

Проверка кадра

Проверка распознавания

Проверка циклической избыточности

Механизмы ограничения ошибок

Каждый узел обслуживают два счетчика ошибок: счетчик ошибок передачи и счетчик ошибок приема. Существуют правила, описывающие условия повышения и/или понижения значений этих счетчиков. По существу, передатчик, обнаруживший сбой, повышает значение своего счетчика ошибок передачи быстрее, чем слушающие узлы повысят значения своих счетчиков ошибок приема. Это потому, что есть большая вероятность, что сбоит сам передатчик!

Узел начинает работу в режиме Error Active. Когда значение любого из двух счетчиков ошибок превысит 127, узел перейдет в состояние Error Passive, а когда значение счетчика ошибок передачи превысит 255, узел перейдёт в состояние Bus Off.

• Узел в режиме Error Active при обнаружении ошибки будет передавать флаги активной ошибки (Active Error Flags).

• Узел в режиме Error Passive при обнаружении ошибки будет передавать флаги пассивной ошибки (Passive Error Flags).

• Узел в режиме Bus Off не будет передавать ничего.

Когда значение счетчика ошибок передачи превысит 127 пунктов (т.е. после 16 попыток), узел A перейдёт в режим Error Passive. Разница в том, что теперь он будет передавать флаги пассивной ошибки. Флаг пассивной ошибки содержит 6 рецессивных битов и не будет нарушать передачу других данных по шине – поэтому другие узлы не услышат жалобы A на ошибки шины. Однако A продолжит повышать значение счетчика ошибок передачи. Когда он превысит 255 пунктов, узел A окончательно сдастся и перейдет в режим Bus Off.

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

• «Предупреждение об ошибке» (Error Warning) – значение одного или обеих счетчиков ошибок превысило 96 пунктов

• Bus Off, как описано выше.

Некотрые, но не все (!), контроллеры также предоставляют бит для состояния Error Passive. Немногие контроллеры также предоставляют прямой доступ к счетчикам ошибок.

Режимы сбоев шины

Стандарт ISO 11898 перечисляет несколько режимов сбоев кабеля шины CAN:

3.CAN_H короткозамкнутый на напряжение батаре

4.CAN_L короткозамкнутый на землю

5.CAN_H короткозамкнутый на землю

6.CAN_L короткозамкнутый на напряжение батареи

7.CAN_L короткозамкнутый на провод

8.CAN_H и CAN_L прерваны в одном и том же месте

9.Потеря соединения с оконечной нагрузкой сети

Для сбоев 1–6 и 9 «рекомендовано», чтобы шина сохраняла работоспособность путём снижения соотношения сигнал/шум (S/N), а в случае сбоя 8 – чтобы исходная подсистема сохранила работоспособность. Для сбоя 7 существует «опциональная» возможность сохранения работоспособности путём снижения соотношения сигнал/шум (S/N).

На практике система CAN, построенная на приемопередатчиках типа 82C250, не сохранит работоспособность при сбоях 1–7, а при сбоях 8–9 может как сохранить, так и не сохранить.

Существуют «устойчивые к сбоям» драйверы, такие как TJA1053, способные обрабатывать все сбои. Обычно за эту устойчивость приходится платить ограничением максимальной скорости; для TJA1053 она составляет 125 кбит/с.

По материалам компании Kvaser . С оригинальными текстами на английском языке можно ознакомиться на сайте компании Kvaser , перейдя по этой ссылке .

Читайте также: