CAN bus (англ. Controller Area Network - сеть контроллеров) – это промышленный сетевой стандарт для передачи данных с высокой степенью надежности и защищенности. Первоначально был ориентирован на объединение в одну сеть датчиков и исполнительных механизмов. Шина CAN была разработана компанией Robert Bosch GmbH в середине 1980-х. На сегодняшний день controller area network является одним из самых распространенных решений в промышленной автоматизации, автоматизации зданий и прочих отраслях.

CAN bus построен на сетевой модели OSI и использует 2 уровня этой модели: физический и канальный. Поскольку не предусмотрено никакого протокола прикладного уровня, возникают проблемы с использованием технологии controller area network в распределенных системах управления, . Это привело к появлению различных протоколов основанных на этой технологии. Самые известные из них: и .

CAN bus описание основных свойств:

• Каждое устройство обладает своим приоритетом.
• Легкость модернизации и изменения системы.
• широковещательный прием сообщений с синхронизацией времени.
• Возможность построения многомастерных сетей с несколькими ведущими устройствами.
• Способность к обнаружению ошибок.
• Работа в режиме жесткого реального времени.
• Высокая устойчивость к помехам.
• Широкий диапазон скоростей работы.

Среди недостатков шины CAN выделяют:

• Отсутствие единого общепринятого стандарта на протокол высокого уровня.
• Длина сети обратно пропорциональна скорости передачи.
• Высокая стоимость CAN – устройств.

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

Распиновка разъема D-sub для CAN bus выглядит следующим образом:

Канальный уровень controller area network состоит из подуровней LLC и MAC. Шина CAN не предусматривает адресацию узлов. Широковещательные сообщения имеют специальный идентификатор, указывающий какому устройству нужно принять данные. Когда сеть свободна, любое устройство может начать передачу. Однако каждое сообщение имеет свой приоритет при получении доступа к шине. Поэтому передачу осуществит устройство с сообщением наивысшего приоритета.

Для определения ошибок используются следующие механизмы:

• Каждый бит проверяется передатчиком.
• Контроль циклически-избыточным кодом (CRC - Cyclic Redundancy Check).
• Каждое сообщение проверяется.

Сообщение в CAN bus состоит из фреймов. Существует 4 различных типа фреймов:

• DATA FRAME - «фрейм данных»
• REMOTE FRAME - «фрейм вызова»
• ERROR FRAME - «фрейм ошибок»
• OVERLOAD FRAME - «фрейм перегрузки»

Структура сообщения CAN bus выглядит следующим образом.

Описание шины CAN

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

Идея заключалась в том, чтобы создать сетевое решение для распределённых систем, работающих в реальном времени. Первоначально CAN применялся в автомобилях, но затем область его применения расширилась и на проблемы автоматизации технологических процессов.

CAN обеспечивает высокий уровень защиты данных от повреждения даже при работе в сложных условиях (сильные помехи), при этом достигается достаточно большая скорость передачи данных (до 1 Mbit/s). Важным достоинством CAN является также то, что разработчик системы может влиять на приоритет сообщений с тем чтобы самые важные из них не ожидали в очереди на отправку. Это свойство CAN позволяет строить сети, поддерживающие реальный масштаб времени.

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

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

Немалую роль играет и возможность поддержки разнотипных физических сред передачи данных? от дешевой витой пары до оптоволокна и радиоканала. А ряд оригинальных механизмов сетевого взаимодействия (мультимастерность, широковещание, побитовый арбитраж) в сочетании с высокой скоростью передачи данных (до 1 Мбит/с) способствуют эффективной реализации режима реального времени в системах распределенного управления.

Топология сети CAN.

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

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

CAN контроллеры соединяются с помощью шины, которая имеет как минимум два провода CAN_H и CAN_L , по которым передаются сигналы при помощи специализированных ИМС приемо-передатчиков. Кроме того, ИМС приемо-передатчиков реализуют дополнительные сервисные функции:

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

Наиболее широкое распространение получили два типа приемоперадатчиков (трансиверов):

"High Speed" приемопередатчики (ISO 11898-2),
"Fault Tolerant" приемопередатчики

Трансиверы, выполненные в соответствии со стандартом "High-Speed" (ISO11898-2), наиболее просты, дешевы и дают возможность передавать данные со скоростью до 1 Мбит/c. "Fault-Tolerant" приемопередатчики (не чувствительные к повреждениям на шине) позволяют построить высоконадежную малопотребляющую сеть со скоростями передачи данных не выше 125 кбит/c.

Физический уровень канала CAN.

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411). В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898.

ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом.

Максимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/s. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью распространения сигнала и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети.

Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице: скорость передачи максимальная длина сети 1000 Кбит/сек 40 метров 500 Кбит/сек 100 метров 250 Кбит/сек 200 метров 125 Кбит/сек 500 метров 10 Кбит/сек 6 километров.

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.

Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L.
Логическая единица - в случае когда сигналы CAN_HI и CAN_LO одинаковы (отличаются менее чем на 0.5 В).
Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях.
Логический ноль - называется доминантным битом, а логическая единица - рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN.

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

Арбитраж шины CAN.

Быстродействие CAN сети (до 1 Mbit/s) достигается благодаря механизму недеструктивного арбитража шины посредством сравнения бит конкурирующих сообщений. Т.е. если случится так что одновременно начнут передачу несколько контроллеров, то каждый из них сравнивает бит, который собирается передать на шину с битом, который пытается передать на шину конкурирующий контроллер. Если значения этих битов равны оба контроллера пытаются передать следующий бит. И так происходит до тех пор пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал) будет продолжать передачу, а другой(другие) контроллер прервёт свою передачу до того времени пока шина вновь не освободится. Конечно,если шина в данный момент занята,то контроллер не начнет передачу до момента её освобождения.

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

Структура формата передачи данных.

Данные по CAN сети пересылаются в виде отдельных кадров стандартного формата. Наиболее важными полями являются поле идентификатора (identifier) и собственно данные (data).

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

Более интересным представляется использование идентификаторов в качестве основного инструмента, используемого в процедуре разрешения коллизий. В CAN в качестве основного критерия для разбора коллизий, для принятия решения, кому отдать эфир, используется приоритет сообщений. Если одновременно несколько станций начали передачу, и при этом произошла коллизия, происходит суперпозиция передаваемых идентификаторов. Идентификаторы последовательно, побитно (bitwise), начиная со старшего, налагаются друг на друга и в их "противоборстве" выигрывает тот, у кого меньше арифметическое значение идентификатора, а значит, выше приоритет. Доминантный "нуль" подавит единицы и в любом случае к концу передачи поля идентификатора оно станет равно более приоритетному значению. Таким образом, система позволяет на уровне проектирования (и определения идентификатра) для любого сообщения в системе заранее предопределить его приоритетность в обслуживании.

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

Форматы кадра.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

Data Frame
Remote Frame
Error Frame
Overload Frame

Data Frame - это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей: поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть.

Поле арбитража состоит в свою очередь из:

для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

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

Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал). Поле данных (data field) содержит от 0 до 8 байт данных поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Remote Frame - это Data Frame без поля данных и с выставленным битом RTR (1 - рецессивные бит). Основное предназначение Remote кадра - это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame - это сообщение которое явно нарушает формат сообщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

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

Мехнизм обработки ошибок.

Надежность CAN сети определяется также механизмами обнаружения ошибок. Стандарт CAN определяет следующие методы обнаружения ошибок в сети CAN:

Check Bit monitoring
Bit stuffing
Frame check
ACKnowledgement Check
Check CRC

Check Bit monitoring - каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.

Bit stuffing - когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check - некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check - каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check - каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

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

Кроме того, каждый узел ведет два счетчика ошибок:

Transmit Error Counter (счетчик ошибок передачи) и
Receive Error Counter (счетчик ошибок приема).

Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

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

Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют.

Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла.

Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

Однако сетевых сервисов спецификации Robert Bosch CAN Specification 2.0A/B и международного стандарта ISO 11898 зачастую явно недостаточно для эффективной разработки CAN-сетей. Дело в том, что упомянутые документы описывают лишь два самых нижних уровня эталонной (семиуровневой) модели взаимосвязи открытых систем OSI/ISO физический и канальный. Определены форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок, некоторые физические параметры среды передачи данных (только в ISO 11898) и др.
Но "за кадром" остаются такие важные на этапе разработки моменты, как адресация узлов, распределение между ними CAN-идентификаторов, интерпретация содержимого фрейма данных, передача данных длиной более 8 байт и др.

В CAN не существует явной адресации сообщений и узлов, сообщения не имеют явной адресации приемника. Источник выставляет на шину свой идентификатор и данные, а приемник самостоятельно, исходя из решаемых задач, обрабатывет принятые данные от данного источника, либо игнорирует их.
Протокол CAN нигде не указывает что поле арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле арбитража или в поле данных, или присутствовать и там, и там).

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

Точно также протокол не запрещает использовать поле арбитража для передачи данных.

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

Поэтому с началом массового выпуска CAN- компонентов и широкого распространения CAN-приложений рядом независимых компаний и некоммерческих ассоциаций в области систем промышленной автоматизации, транспорта и т. д. проводилась (и продолжается по сей день) работа по созданию и стандартизации спецификаций протоколов верхнего уровня HLP (Higher Level Protocol) для CAN-сетей.

Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP - Higher Layer Protocols).

Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

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

CiA, а именно:
CAL/ CANopen,
CAN Kingdom,
DeviceNet и

CAL/CANopen

Разработка и поддержка открытого протокола прикладного уровня для сетей промышленной автоматизации были одними из приоритетных целей создания организации CiA в 1992 году. Основой такого протокола послужил HLP, разработанный фирмой Philips, после доработки и усовершенствования которого рабочей группой CiA, в 1993 году была опубликована спецификация CAL CAN Application Level (CiA DS 20x).

Сетевые CAN приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, в промышленном оборудовании. Результатом дополнения CAL (точнее, некоторого его подмножества) системой профилей (устройств, интерфейсов, приложений и т. д.) и спецификациями физического уровня (типы соединителей, правила битового квантования и т. д.) явилось появление более "конкретного" стандарта протокола CANopen. По существу CANopen является приложением прикладного уровня CAL. Первоначально CANopen предназначался для сетей управления движущимися механизмами в системах промышленной автоматики.
Однако впоследствии протокол нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий. CANopen базируется на двух уровнях стандарта CAN (ISO 11898, Bosch CAN Specification 2.0 A/B). В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных двухпроводная дифференциальная линия), CANopen содержит собственные правила битового квантования, а также определяет три рекомендуемых типа соединителей. Разводкой контактов для всех типов соединителей предусмотрена возможность подачи питания на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определены восемь градаций скоростей передачи данных: 1 Мбит/с, 800 кбит/с, 500, 250, 125, 50, 20 и 10 кбит/с. Поддержка скорости 20 кбит/с является обязательной для всех модулей.

Протокол шведской компании KVASER-AB (www.kvaser.se) занимает особое место среди CAN HLP благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе.

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

CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике от надувных лодок и систем наведения на цели до сверхзвуковых истребителей и ракет. Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей от независимых производителей. CAN Kingdom не является "готовым" протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов метапротокол, с помощью которых можно "собрать" протокол под конкретную сеть модулей. Этим достигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью "закрытости" оригинального протокола. Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип: "Модули обслуживают сеть" (MSN Modules Serves the Network) в отличие от принципа "Сеть обслуживает пользователей" (NSM Network Serves the Modules), свойственного компьютерным сетям.

В сеть CAN Kingdom не существует каких-либо рекомендуемых скоростей передачи данных. Но за первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 кбит/ с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.

DeviceNet протокол, разработанный и опубликованный в 1994 году компанией Allen-Bradley (www.ab.com) корпорации Rockwell и впоследствии переданный в ведение специально организованной для его поддержки ассоциации ODVA (Open DeviceNet Vendor Association Inc., www.odva.org).

DeviceNet недорогое, простое и эффективное решение для объединения разнообразных устройств промышленной автоматизации независимых производителей в единую систему: фото-, термодатчики, стартеры, считыватели штриховых кодов, элементы человеко- машинного интерфейса клавиатуры, дисплейные панели, наряду с управляющими устройствами PLC, компьютерами и т. д. При разработке протокола помимо снижения стоимости также стояла задача упрощения и унификации диагностики подобных устройств. Первые устройства, удовлетворяющие спецификации DeviceNet, появились на рынке в начале 1995 года. DeviceNet также построен на двух нижних уровнях стандарта CAN, дополненных более детальными, чем в других HLP, спецификациями физической среды.

Сеть DeviceNet имеет шинную топологию с отводами. Физической средой передачи является 4- проводной кабель (CAN_H, CAN_L, Vcc, Ground), причем возможны две его разновидности: толстый (внешний диаметр 12,2 мм) и тонкий (6,9 мм). Определены лишь три значения скорости передачи данных 125, 250 и 500 кбит/с.

Важной особенностью сети DeviceNet является возможность питания модулей непосредственно от сетевого кабеля (24 В, до 8 А на толстом кабеле), а также допускается применение нескольких источников питания в любой точке шины. Все это дает возможность построения автономной сети, не зависящей от наличия или качества внешнего питания, а при необходимости позволит легко демонтировать и снова развернуть систему на новом месте.

Сеть DeviceNet допускает "горячее" (без обесточивания сети) подключение и отключение модулей. Стандарт DeviceNet содержит также подробное описание многочисленных типов переходников, разветвителей (одиночных и многопортовых), соединителей (Mini, Micro), сетевых отводов и т. п. При описании организации типов данных, сетевого поведения модулей в DeviceNet используется объектно-ориентированная модель.

Максимальное число узлов в сети DeviceNet 64.

SDS (Smart Distributed System)

SDS разработка компании Honeywell Inc. (Micro Switch Division, www.honeywell.sensing.com). Наряду со стандартом DeviceNet, SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальными датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации. По степени завершенности от спецификаций физической среды до прикладного уровня, ориентировке на снижение стоимости, SDS-стандарт напоминает DeviceNet. Шинная топология представляет собой линейную шину (магистраль или транк) с короткими отводами.

Определены два базовых типа кабельной разводки:

Mini (применяемый при сборке транка сети) 4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем и
Micro (для подключения физических устройств к сети) 4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта для экрана кабеля.

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

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

Шина CAN-bus была создана в конце 80-х годов фирмой Robert Bosch GmbH (Германия) как решение для распределенных систем, работающих в режиме реального времени. Отличительной особенностью шины является ее высокая помехозащищенность. Дополнительным преимуществом шины CAN выступает ее устойчивость к механическим повреждениям - замыкание проводников шины на общий провод, питание или между собой не приводит к выходу из строя устройств. Более того, некоторые модификации шины способны функционировать при обрыве одного из проводников.

CAN-шина в промышленных сетях

Полевая шина CAN (Controller Area Network) характеризуется высокими скоростью передачи данных и помехоустойчивостью, а также способностью обнаруживать любые возникающие ошибки. Благодаря этому CAN сегодня широко используется в таких областях, как автомобильный и железнодорожный транспорт, промышленная автоматика, авиация, системы доступа и контроля. По данным ассоциации CiA (CAN in Automation, www.can-cia.de), в настоящее время в эксплуатации находится около 300 млн CAN-узлов по всему миру. В Германии CAN-шина занимает первое место по популярности среди остальных полевых шин.

Характеристики протокола CAN Преимущества CAN

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

Испытанный стандарт. Протокол CAN активно используется уже более 20 лет, что очень важно для таких консервативных областей как железнодорожный транспорт или судостроение. CAN был разработан в 1980 г. фирмой Robert Bosch для автомобильной промышленности. CAN-интерфейс регламентирован международными стандартами ISO 11898 для высокоскоростных и ISO 11519-1 для низкоскоростных приложений. Низкая стоимость определяется хорошим соотношением цена/производительность, также широкой доступностью CAN-контроллеров на рынке. Надежность определяется линейной структурой шины и равноправностью ее узлов, так называемой мультимастерностью (Multi Master Bus), при которой каждый узел CAN может получить доступ к шине. Любое сообщение может быть послано одному или нескольким узлам. Все узлы одновременно считывают с шины одну и ту же информацию, и каждый из них решает, принять данное сообщение или игнорировать его. Одновременный прием очень важен для синхронизации в системах управления. Отказавшие узлы отключаются от обмена по шине.

Высокая помехоустойчивость достигается благодаря подавлению синфазных помех дифференциальным приемопередатчиком, работе встроенных механизмов обнаружения ошибок (одна необнаруженная ошибка за 1000 лет при ежедневной 8-часовой работе сети на скорости 500 Кбит/с), повтору ошибочных сообщений, отключению неисправных узлов от обмена по шине и устойчивости к электромагнитным помехам.

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

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

Приложения CAN

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

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

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

Физический уровень CAN-шины представляет собой соединение «монтажное И» между всеми устройствами, подключенными к ней. Дифференциальные сигнальные линии называются CAN_H и CAN_L и в статическом состоянии находятся под потенциалом 2,5 В. Лог. 1 (рецессивный бит) обозначает состояние шины, при котором уровень на линии CAN_H выше, чем уровень CAN_L. При лог. 0 (доминантный бит) уровень на линии CAN_H ниже, чем уровень CAN_L. Принято следующее соглашение о состоянии шины: пассивное состояние шины соответствует уровню лог. 1, а активное - уровню лог. 0. Когда сообщения не передаются по шине, она находится в пассивном состоянии. Передача сообщения всегда начинается с доминантного бита. Логика работы шины соответствует «проводному И»: доминантный бит «0» подавляет рецессивный бит «1» (рис. 12.1).

Рис. 12.1. Логика работы CAN шины

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

Максимальная скорость передачи данных составляет 1 Мбит/с при длине шины 40 м и около 40 Кбит/с при длине шины 1000 м.

Разновидности CAN

В настоящее время доступны различные устройства с CAN-интерфейсом, которые помимо передачи данных из одной точки в другую позволяют реализовать синхронизацию процессов и обслуживание по приоритетам. Более ранние реализации CAN-контроллеров используют кадры с 11-разрядным идентификатором и возможностью адресации до 2048 сообщений и соответствуют спецификации CAN V. 2.0A. Такие контроллеры носят название Basic CAN и характеризуются сильной загруженностью центрального процессора (ЦПУ), так как каждое входящее сообщение запоминается в памяти и ЦПУ решает, нужны ему данные сообщения или нет (рис. 12.2). Контроллеры Basic CAN содержат один передающий буфер и один или два приемных буфера сообщений. Чтобы послать или получить сообщение, требуется задействовать ЦПУ через прерывания «сообщение_послано» и «сообщение_получено». В результате проверки каждого входящего сообщения загрузка ЦПУ очень велика, что ограничивает реальную скорость обмена по сети. По этой причине такие контроллеры используются в сетях CAN с низкой скоростью обмена и/или малым количеством сообщений.

Рис. 12.2. Структура контроллера Basic CAN

Большинство выпускаемых сегодня CAN-контроллеров используют расширенные кадры сообщений с идентификатором длиной 29 разрядов, что позволяет адресовать до 536 млн сообщений. Такие контроллеры соответствуют спецификации CAN V. 2.0B (active) и называются контроллеры Full-CAN. В них предусмотрен буфер для нескольких сообщений, причем каждое сообщение имеет свою маску, и фильтрация осуществляется по соответствию идентификатора маске.

В случае Full-CAN ЦПУ максимально разгружено, поскольку не обрабатывает ненужные сообщения (рис. 12.3). При приеме сообщения с идентификатором, соответствующим маске, оно запоминается в специальной зоне двухпортового ОЗУ, и работа ЦПУ прерывается. Full-CAN имеет также специальный тип сообщения, которое означает: «у кого бы ни находилась эта информация, пожалуйста, пошлите ее сейчас же». Контроллер Full-CAN автоматически прослушивает все сообщения и посылает запрошенную информацию.

Рис. 12.3. Структура контроллера Full-CAN

До недавнего времени в промышленности был широко распространен Basic CAN с 11-разрядным идентификатором. Этот протокол допускает простую связь между микроконтроллерами и периферийными устройствами при скорости обмена вплоть до 250 Кбит/с. Однако при стремительном удешевлении CAN-контроллеров использование Full-CAN стало оправданным и для связи с медленными устройствами. Если в промышленных приложениях требуется высокоскоростной (до 1 Мбит/с) обмен данными, то непременно следует использовать Full-CAN.

Арбитраж узлов CAN-шины

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

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

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

Если передача узла А приостанавливается узлом B, посылающим сообщение с более высоким приоритетом, то, как только шина освободится, будет сделана другая попытка передачи сообщения от узла A. Этот принцип получил название CSMA/CA: Carrier Sense Multiple Access/Collision Avoidance (общий доступ с опросом/предотвращение конфликтов). Такой режим в отличие от Ethernet не позволяет конфликтующим узлам в шине выяснять отношения, а сразу выявляет победителя и сокращает время обмена.

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

Формат сообщений

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

Рис. 12.4. Кадр данных (Data Frame)

Для передачи данных служит кадр данных - Data Frame (рис. 12.4), который содержит:

• идентификатор, указывающий на тип сообщения («скорость_двигателя», «температура_масла») и на приоритет доступа к шине. Поле идентификатора содержит различное количество бит в зависимости от разновидности протокола: в стандартном формате CAN V2.0A предусмотрен 11-разрядный идентификатор, а в расширенном CAN V2.0B - 29-разрядный;
• поле данных, содержащее соответствующее сообщение («скорость_двигателя»= 6000 об/мин, «температура_масла»=110 °C) длиной до восьми байт;
• два байта контрольной суммы - Cyclic Redundancy Check (CRC) для выявления и коррекции ошибок передачи.

Для запроса информации узел CAN использует кадр запроса данных Remote Frame (рис. 12.5), который содержит:

• идентификатор, определяющий тип запрашиваемой информации («скорость_ двигателя», «температура_масла») и приоритет сообщения;
• два байта контрольной суммы CRC .

Рис. 12.5. Кадр запроса данных Remote Frame

В этом случае за идентификатором не следуют данные и код длины данных не имеет прямого отношения к количеству байт данных. Узел, которому предложено передать информацию (датчик температуры масла), передает кадр данных, содержащий требуемую информацию. Таким образом, если узел А направляет узлу В кадр запроса с идентификатором «температура_масла», то узел В опрашивает датчик температуры и направляет узлу А кадр данных, содержащий идентификатор «температура_масла» и требуемую информацию.

Дополнительная информация, содержащаяся в кадре, позволяет определить формат и синхронизацию протокола передачи сообщения и тип посылки:

• какое сообщение послано - запрос о данных или собственно данные определяют бит удаленного запроса передачи (RTR для 11-разрядного идентификатора и SRR для 29-разрядного);
• код длины данных, сообщающий, сколько байтов данных содержит сообщение; все узлы принимают кадр данных, но те из них, которым эта информация не нужна, ее не сохраняют;
• для обеспечения синхронизации и контроля кадр содержит поля начала кадра Start of Frame, конца кадра End of Frame и подтверждения Acknowledgement Field;
• вход в режим синхронизации на шине осуществляется первым битом поля Start of Frame, далее синхронизация поддерживается фронтом при смене уровня посылаемых битов;
• используется механизм битстаффинга - вставка дополнительного бита при следующих подряд пяти нулях или единицах.

Обнаружение ошибок

Сигнализация об ошибках происходит путем передачи кадра ошибки Error Frame. Он инициируется любым узлом, обнаружившим ошибку. CAN-контроллеры используют метод статистической обработки ошибок. Каждый узел содержит счетчики ошибок при передаче и приеме Transmit Error Counter и Receive Error Counter. Если передатчик или приемник обнаруживают ошибку, значение соответствующего счетчика увеличивается. Когда значение счетчика превышает некоторый предел, текущая передача прерывается. Узел выдает сигнал об ошибке в виде Error Frame, где выставляет активный доминантный флаг ошибки длиной 6 бит. После этого узел, передача которого была прервана, повторяет сообщение. Ненадежным или частично поврежденным узлам разрешено посылать лишь пассивный рецессивный флаг ошибки.

В CAN существует несколько разновидностей ошибок. Из них три типа на уровне сообщений:

• CRC Error - ошибка контрольной суммы (при несовпадении принятой в поле CRC и вычисленной контрольных сумм).
• Form Error - ошибка формата кадра при несоответствии принятого сообщения формату CAN.
• Acknowledgement Error - ошибка подтверждения приема сообщения, если ни один из узлов не подтвердил правильного получения сообщения.

Кроме того, существует два типа ошибок на битовом уровне:

• Bit Error - обнаружение активным узлом расхождения между посланным в шину уровнем и фактическим значением за счет реализации узлом механизма самоконтроля.
• Stuff Error - наличие в поле сообщения шести следующих подряд бит 0 или 1 (ошибка битстаффинга).

Благодаря этим механизмам обнаружения и коррекции ошибок вероятность пропуска ошибки крайне мала. Например, при скорости 500 Кбит/с, загруженности шины 25 % и использовании в течение 2000 часов в год возникает лишь одна необнаруженная ошибка за 1000 лет. Кроме того, в шине невозможна ситуация блокировки неисправным узлом работы всей сети. Такие узлы обнаруживаются и отключаются от обмена по шине.

К современным автомобилям предъявляются всё более высокие требования. Требования к безопасности езды, комфорту во время езды, экологической безопасности и экономичности постоянно возрастают.

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

Благодаря этому развитию растёт также доля электронных систем. В современных автомобилях, в зависимости от класса и оснащения автомобиля, применяется от 25 до 60 электронных систем, которые должны быть все связаны между собой проводной связью.

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

История шины CAN

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

• невысокая стоимость в серийном производстве
• способность работать в режиме реального времени для быстродействия
• высокая надёжность
• высокая степень защищённости от электромагнитных помех

Самая распространённая система обмена данными — CAN-bus

• 1983 Начало разработки CAN (Бош)
• 1985 Начало кооперации с Интел по разработке чипа
• 1988 Первый серийный тип CAN от компании Intel начинает внедрение CAN для грузовых автомобилей
• 1991 Первое применение CAN в серийном автомобиле (S-класс)
• 1994 Вводится международный стандарт для CAN (ISO 11898)
• 1997 Первое использование CAN в салоне (С-класс)
• 2001 Использование CAN в малолитражных автомобилях (Опель Корса) в приводе и кузове

Что означает CAN ?

CAN означает Controller Area Network

Преимущества передачи данных CAN-BUS

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

Что такое CAN-BUS ?

Систему передачи данных CAN-бус можно представить в виде автобуса. Так же, как и автобус предназначен для перевозки множества пассажиров, так и
система CAN-бус передаёт множество информации. Без системы CAN-бус всю информацию надо было бы передавать к управляющим устройствам по огромному количеству проводных соединений. Это означает, что для каждой информации должен быть один проводной канал.

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

Схема «звезда»

• по схеме «звезда» все элементы обмена данными замыкаются на один центр (блок управления)
• если блок управления выходит из строя, то соединение нарушается

Схема «кольцо»

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

Линейная схема

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

Устройство системы обмена данными

Линейная схема применяется в автомобилях чаще всего, в настоящей статье рассматривается преимущественно эта схема системы CAN-бус.

• Сетевой узел : В него входят микроконтроллер, CAN-контроллер и бусдрайвер
• Микроконтроллер : Предназначен для непрерывного управления CAN-контроллером и обработки передаваемых и принимаемых данных.
• CAN-контроллер : Предназначен для обеспечения режимов передачи и приёма.
• Бусдрайвер : Обеспечивает уровень передачи, а также приёма.
• Канал связи : Представляет собой двухжильный проводник(для обоих видов сигналов: CAN-High и CAN-Low). Для уменьшения электромагнитных помех проводники экранированы.
• Перемычка бус : Нагрузочный резистор в 120 В предотвращает появление эхо-сигнала на концах проводника и устраняют искажение сигнала.

Как работает бус?

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

Автомобиль начинает движение, но дверь со стороны водителя закрыта неплотно. Чтобы предупредить водителя о этом, модулю чек-контроля необходимы две информации:

• автомобиль движется.
• дверь со стороны водителя открыта.

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

Система передачи данных CAN-бус представляет собой систему мультимастер – систему множественного доступа, что означает следующее:

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

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

Это могло бы привести к «столкновению» данных. Следовательно, нужно следить за порядком. Поэтому в системе CAN-бус существует чёткая иерархия — кто должен послать свою информацию самым первым, а кто должен подождать. При программировании сетевых узлов была определена очерёдность, в зависимости от важности тех или иных данных. Согласно очерёдности, данные с более высоким приоритетным правом первенствуют по отношению к данным с более низким приоритетным правом. Если идёт отправка данных с сетевого узла с высоким приоритетом, то остальные сетевые узлы автоматически.

Как действует иерархия (логика передачи) в системе CAN-бус?

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

В системе CAN определяется различие между доминантными и рецессивными уровнями передачи. Рецессивный уровень имеет значение 1, а доминантный
уровень имеет значение 0. Теперь, если многие блоки управления одновременно посылают передачи доминантного и рецессивного уровня, то управляющее
устройство с доминантным уровнем имеет право отправить своё сообщение в первую очередь.

На этом примере можно ещё раз объяснить доступ к передаче данных. В данном случае три сетевые узла хотят передать по системе свои данные. Во время процесса арбитражной оценки — выбора очерёдности — блок управления S1 прервёт свою попытку передачи в пункте А, так его рецессивный уровень преодолевается доминантными уровнями других управляющих устройств S2 и S3.

Управляющее устройство S2 прервёт свою попытку передачи в пункте В по той же самой причине, что была указана ранее. Таким образом верх одерживает управляющее устройство S3, оно может теперь передать своё сообщение.

Что такое протокол данных?

Передача данных происходит по протоколу данных в очень короткие промежутки времени. Протокол состоит из огромного количества бит информации, расположенных в определённом порядке. Число бит зависит от величины поля данных. Бит является наименьшей единицей информации, восемь бит образуют байт = послание. Это послание имеет цифровую форму, и может выражаться значениями 0 или 1.

Передача данных CAN-бус в легковом Автомобиле

В наши дни в современных автомобилях находят применение 2 системы CAN-бус:
Высокоскоростная передача данных – High=Speed-Bus (ISO 11898)

• SAE CAN Class C.
• передача данных 125 Кбит/сек – 1Мбит/сек.
• протяжённость передачи до 40 метров при 1 Мбит/сек.
• выходной ток передачи > 25 мА.
• низкое потребление тока.
• до 30 сетевых узлов.

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

Низкоскоростная передача данных – Low-Speed-Bus (ISO 11519-2)

• SAE CAN Class В.
• передача данных 10 Кбит/сек – 125 Кбит/сек.
• максимальная протяжённость передачи зависит от объёма передачи.
• выходной ток передачи < 1 мА.
• система устойчива к короткому замыканию.
• низкое потребление тока.
• до 32 сетевых узлов.

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

Диагностика системы CAN-BUS

Возможные неисправности системы CAN-бус:

• обрыв проводников.
• замыкание на массу.
• замыкание на батарею
• замыкание CAN-High / CAN-Low..
• cлишком низкое напряжение питания / разряжен аккумулятор.
• отсутствие резисторных перемычек.
• напряжения помех, например, неисправная катушка зажигания, что вызывает искажение сигнала.

Поиск неисправности:

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

Поиск причин несиправностей

Перед началом поиска причины неисправности необходимо нет ли в данном автомобиле дополнительных устройств, которые имеют

в системе передачи доступ к информации системы передачи данных. Может случиться, что в результате проникновения в систему она была нарушена. Возможности поиска неисправностей в системе передачи данных зависят от многих факторов. Решающим является то, какие возможности предоставил производитель. Это может быть поиск неисправности с помощью прибора для диагностики, если в Вашем распоряжении находится подходящий прибор, или Вы располагаете «только» тестером и осциллоскопом. Также очень важно иметь в своём распоряжении специальные данные по автомобилю (электрические схемы, подробное описание системы передачи данных и т.д.), во избежание разрыва сетевого единства автомобиля.

Во время поиска неисправности, всё равно, с помощью тестера или осциллоскопа, необходимо действовать по операциям, использовать структурный подход. Это означает, что неисправность можно локализовать простым «прощупыванием», то есть опробовать в работе, чтобы ограничиться в дальнейшем только самыми необходимыми измерениями. Для того, что Вы могли себе это представить нагляднее, возьмём в качестве примера поиска неисправности конкретный автомобиль. В нашем случае это будет (кузов W210).

Было заявлено о следующей неисправности:

Стеклоподъёмник со стороны пассажира не работает.

Проверка работоспособности:

1. Можно ли воздействовать на стеклоподъёмник с места водителя?

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

Можно ли воспользоваться другими функциями (например, изменить положен­ие зеркала)?

Если можно воспользоваться другими функциями, то нужно исходить из того, что устройство управлениями дверями и система CAN-бус находятся в рабочем состоянии. Возможной причиной неисправности является поломка выключателя стеклоподъёмника со стороны водителя или электродвигателя стеклоподъёмника со стороны пассажира. Это можно выяснить, если проверить эту функцию с места пассажира. Если стеклоподъёмник работает, то электродвигатель можно исключить. Для поиска неисправности нужно сосредоточиться на выключателе со стороны водителя.

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

Сравнение правильного и неправильного изображений осциллоскопа

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

Здесь отдельные проводники CAN-бус от управляющих устройств сходятся вместе. К распределителю потенциалов можно подключить осциллоскоп безовсяких трудностей.

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

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

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

Для проверки резисторных перемычек нужно, чтобы CAN-бус находился в состоянии покоя (Sleepmode). Управляющие устройства при проведении измерений должны быть подключены. Общее сопротивление, которое складывается параллельно включённых одинаковых резисторов по 120 Ом, составляет 60 Ом. Это сопротивление измеряется между проводниками CAN- High и CAN-Low.

Установка дополнительных устройств

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

Во всемирной сети существуют сайты, где можно найти информацию о способах и местах подключения и установки различных устройств. Эти сведения, разумеется, не дают никаких гарантий, поэтому в любом случае весь риск на себя берёт авторемонтная мастерская, если решится использовать такие данные. Однако в любом случае самый надёжный способ — это ознакомиться с технической документацией производителя автомобиля. Для того, чтобы познакомиться со всеми возможными системами 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 Ом, однако допускается интервал значений сопротивления Ом.

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

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