Описание шины CAN. 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 кбит/с является обязательной для всех модулей.

CAN Kingdom

Протокол шведской компании 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

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 (Controller Area Network - "область, охваченная сетью контроллеров") представляет собой комплекс стандартов для построения распределенных промышленных сетей, который использует последовательную передачу данных в реальном времени с очень высокой степенью надежности и защищенности. Центральное место в CAN занимает протокол канального уровня модели OSI. Первоначально CAN был разработан для автомобильной промышленности, но в настоящее время быстро внедряется в область промышленной автоматизации. Это хорошо продуманный, современный и многообещающий сетевой протокол. Начало развития CAN было положено компанией Bosch в 1983 г., первые микросхемы CANконтроллеров были выпущены фирмами Intel и Philipsв 1987 году, в настоящее время контроллеры и трансиверы CANвыпускаются многими фирмами, в том числе Analog Devices, Inc., Atmel Corp. Cast, Dallas Semiconductor, Freescale, Infineon, Inicore Inc., Intel, Linear Technology, Maxim Integrated Products, Melexis, Microchip, National Semiconductor, NXP, OKI, Renesas Technology Corp., STMicroelectronics, Yamar Electronics, Texas Instruments.

В России интерес к CAN за последние годы сильно возрос, однако контроллерного оборудования для CAN в России крайне мало, в десятки или сотни раз меньше, чем для Modbus или Profibus. Среди протоколов прикладного уровня для работы с CAN наибольшее распространение в России получили CANopen и DeviceNet.

В настоящее время CAN поддерживается 11-ю стандартами ISO, в том числе [ISO - Diagnostics ].

CAN охватывает два style="color:red"> уровня модели OSI: физический и канальный (табл. 2.7). Стандарт не предусматривает никакого протокола прикладного (7-го) уровня модели OSI. Поэтому для его воплощения в жизнь различные фирмы разработали несколько таких протоколов: CANopen (организации CiA), SDS (фирмы Honeywell Micro Switch Division), CAN Kingdom (фирмы Kvaser), DeviceNet (фирмы Allen-Bradley, ставший Европейским стандартом в 2002 г.) и ряд других [Грибанов - Третьяков ].

CAN характеризуется следующими основными свойствами:

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

К недостаткам можно отнести сравнительно высокую стоимость CAN-устройств, отсутствие единого протокола прикладного уровня, а также чрезмерную сложность и запутанность протоколов канального и прикладного уровня, изложенных в стандартах организации CAN in Automation (CiA).

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

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

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

Для электрического соединения устройств с CAN интерфейсом стандарт предусматривает два варианта. Первый вариант состоит в применении Т-образных разветвителей, которые состоят из трех 9-штырьковых разъемов D-sub, расположенных в одном корпусе, одноименные контакты которых соединены между собой. Разветвители имеют один разъем со штырьками и два - с гнездами.

Второй вариант требует наличия в каждом CAN-устройстве двух разъемов. Для включения устройства в сеть кабель разрезают и на его концах устанавливают ответные части разъемов. Устройство включается буквально в разрыв линии передачи. Такой подход позволяет наращивать количество устройств и изменять топологию сети путем добавления в разрыв кабеля новых устройств и кабеля с разъемами на концах. Один из разъемов должен быть со штырьками, второй - с гнездами. Подключение устройств к шине без разъемов не допускается. Согласующий резистор должен располагаться внутри разъема, который подключается к концу кабеля. Для присоединения модулей к CAN-шине должен использоваться 9-штырьковый разъем типа D- Sub. На модуле устанавливается разъем с гнездами, на соединяющем кабеле - со штырьками. Цоколевка разъемов показана в табл. 2.8 .

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

Отметим, что в основанном на CAN стандарте CANopen предусмотрено гораздо большее разнообразие вариантов разъемов, в том числе для плоского кабеля, RJ-10, RJ45, разъемный винтовой клеммник, и еще около десяти вариантов специальной конструкции [Cabling ]. Допускается применение и других разъемов.

Это свойство CAN обеспечивает возможность получения доступа к линии, сравнивая посылаемые в линию логические уровни с тем уровнем, который фактически устанавливается в ней: если передатчик посылает в линию рецессивное состояние, а в ней при этом остается доминантное, значит линия занята. Доступ получает тот узел сети, который может предоставить ей доминантный уровень сигнала. Узлы с рецессивным уровнем покидают линию и ждут следующего случая. Этот метод доступа справедлив и при использовании оптоволоконного канала или беспроводной сети - в этих случаях наличие света или электромагнитной волны всегда будет доминировать над их отсутствием. Вывод на рис. 2.20 позволяет установить пороговое напряжение для входа и уровень синфазного напряжения в линии, когда она находится в рецессивном состоянии. Обычно = 2,5 В. Чтобы установить уровень синфазного напряжения на линии, терминальные сопротивления делят на два по 60 Ом, соединяют их последовательно, а к точке соединения подключают вывод . При симметричной форме импульсов и относительно рецессивного состояния уменьшается уровень излучаемых помех, поскольку приращения токов в каждом из проводов витой пары при переключении логических уровней (см. рис. 2.21) оказываются равными по величине, но обратными по знаку и поэтому компенсируют друг-друга. Вывод имеет несколько назначений. Если на нем установлено состояние логической единицы, трансивер переходит в спящий режим, при котором он потребляет очень малый ток от источника питания, а на выходе устанавливается высокоомное (рецессивное) состояние. "Разбудить" его можно сигналом, поступающим в приемник из линии передачи. Подключение этого вывода к "земле" через сопротивление позволяет установить нужную длительность фронтов импульсов передатчика. Некоторые трансиверы имеют два режима: резервный и спящий, которые отличаются уровнем потребляемого тока и способом перевода в активный режим. Режим пониженного энергопотребления предусмотрен стандартом для экономии заряда аккумуляторных батарей в припаркованном автомобиле. Рис. 2.21. Пояснение понятий рецессивного и доминантного состояния Если сигнал является доминирующим слишком долго (более 1 мс), генератор импульса таймаута (на рис. 2.20 обозначен прямоугольником с импульсом) временно отключает передатчик, поскольку в противном случае модуль может быть навсегда блокирован средствами канального уровня как отказавший. Стандартом предусмотрена возможность подключения к CAN сети любого количества устройств, однако практически оно ограничивается нагрузочной способностью передатчиков (100...200) или задержкой в повторителях. В CAN-трансивере имеется генератор синхроимпульсов с частотой 16 МГц ±0,1%. Ширина одного бита программно устанавливается величиной от 8 до 25 импульсов синхрогенератора, обычно 8 импульсов при скорости передачи 1 Мбит/с и 16 импульсов при 20 кбит/с. Синхронизация всех узлов сети происходит в течение первого такта синхронизации. Процедура обработки битов в приемнике обеспечивает программируемую задержку импульсов синхронизации, необходимую для компенсации времени задержки прохождения сигнала в линии связи и сдвига фазы вследствие дрейфа частоты тактового генератора. Различают два типа синхронизации: жесткую синхронизацию с помощью стартового бита в начале сообщения и ресинхронизацию во время передачи сообщения. С помощью ресинхронизации можно подстроить интервал времени от начала синхронизации до момента, в который измеряется логический уровень принимаемого импульса данных. Интервал подстройки может быть изменен на 1...4 такта. Для определения логического состояния шины уровни принимаемых сигналов измеряются на расстоянии 6-ти тактов синхрогенератора от переднего фронта импульса (бита) при скорости 1 Мбит/с и на расстоянии 14-ти тактов при скорости 20 кбит/с [CAN ] (для сравнения укажем, что в стандартных UART отсчеты берутся посередине импульса). Количество отсчетов может быть 1 или 3 (устанавливается программно). CAN использует синхронную передачу битов. Это повышает пропускную способность канала связи, но требует усложненного процесса синхронизации. Канальный уровень CAN, рассмотренный выше, практически невозможно использовать в SCADA-пакетах, поскольку он оперирует битами, фреймами, полями. Для написания же прикладных программ нужно использовать понятия: переменная, массив, событие, клиент, сервер, имя устройства и т. п. Рассмотрим наиболее распространенный стандарт прикладного уровня CANopen [CANopen ]. Для упрощения применения стандарта вводятся несколько специфических для CANopen понятий. Все функциональные возможности прикладного уровня делятся между так называемыми сервисами (элементами услуг). Программные приложения взаимодействуют между собой путем вызова соответствующих сервисов прикладного уровня. Сервисы обмениваются данными с равными им (одноранговыми) сервисами через CAN-сеть с помощью определенного протокола. Этот протокол описывается в спецификации протокола сервиса. Вводится понятие сервисного примитива , который представляет собой средство (языковую конструкцию), с помощью которого программное приложение взаимодействует с прикладным уровнем. В CANopen существует четыре различных примитива: запрос приложения к прикладному уровню, публикуемый приложением для вызова сервиса; индикация , публикуемая прикладным уровнем для приложения, чтобы сообщить о внутренних событиях, обнаруженных прикладным уровнем или чтобы показать, что сервис запрошен; ответ , публикуемый приложением для прикладного уровня, чтобы ответить на ранее полученную индикацию; подтверждение , публикуемое прикладным уровнем для приложения, чтобы отчитаться о результатах ранее изданного запроса.

25.10.2012

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

* Что такое CAN?

* Взаимосвязь открытых систем (Open System Interconnection (OSI))

* Controller Area Network (CAN)

* Основные принципы CAN

* Как выглядит CAN шина на примере автомобилей произведённых в Японии

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

Что такое CAN ?

Controller Area Network - это понятие вошло в обиход после того, как в начале 1980-х годов в Robert Bosch GmbH разработали стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Одно их первых внедрений в автомобильной промышленности было осуществлено на нескольких моделях автомобилей Mercedes-Benz в 1992 году. До этого момента электронное управление исполнительными функциями строилось по системе - один блок управления принимал электронные сигналы с различных датчиков и после их обработки посылал соответствующие команды на исполнительные устройства (такие как бензонасос, форсунки, катушки зажигания и прочие...). Увеличение объёма функций управления автомобилем, передаваемое электронике, привело к появлению таких дополнительных систем как ABS, SRS, AT, Immobilaser и других... Совмещение этих функций в одном ЭБУ привело бы к его громоздкости и чрезмерной сложности, а так же к потере надёжности, когда выход из строя одной системы мог бы привести к потере управляемости всего автомобиля. Поэтому автопроизводители пошли по пути разделения функций управления и выделения всех систем в отдельные блоки. А для того, чтобы увязать все системы в единое целое для решения общих задач управления автомобилем, на помощь пришёл коммуникационный стандарт CAN от Robert Bosch GmbH и это всё шире и шире стало применяться в автомобилестроении. На сегодняшний день практически каждый новый автомобиль оснащён этой системой.

Всё в принципе просто и понятно, но как устроена CAN шина и на чём основывается принцип её работы? Вот один из примеров взаимосвязи электронных блоков управления и устройств завязанных в единую бортовую коммуникационную сеть автомобиля,- рис. 1

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

Немного предыстории - Взаимосвязь открытых систем (Open System Interconnection (OSI)).

Это очевидно, что если два или более микропроцессора взаимосвязаны в одну систему, то должен использоваться стандартный протокол который определяет, каким образом данные должны быть переданы между сетевыми блоками. Наиболее распространенным примером такого протокола является TCP/IP (Transmission Control Protocol / Internet Protocol ), который используется для подключения хостингов в сети Интернет. Предшественником TCP/IP был протокол - Open System Interconnection (OSI ). Этот протокол был разработан в 1982 году Международным бюро по стандартизации International Organization for Standardization (ISO 7498-1:1994 (E )). OSI протокол иногда называют как «семиуровневая» модель, поскольку он состоит из семи независимых элементов, которые определяют требования к взаимосвязи на различных уровнях взаимодействия.

Вот эти семь уровней:

1) Уровень приложений (Application Layer ) - этот уровень определяет какие приложения (программы) имеют доступ к сети. Например - электронная почта, передача файлов, терминалы удалённого доступа и веб-браузеры.

2) Уровень представления данных (Presentation Layer ) - этот уровень определяет такие моменты, как стандарты сжатия данных и их шифрования.

3) Уровень передачи данных (Transport Layer ) - этот уровень обеспечивает стандарты передачи данных между адресатами, осуществляет контроль ошибок и безопасности.

4) Сетевой уровень (Network Layer ) - этот уровень отвечает за вопросы маршрутизации сетевого трафика данных.

5) Уровень каналов связи (Data Link Laye r ) - этот уровень обеспечивает синхронизацию передачи данных и контроль ошибок.

6) Уровень контроля за сеансами связи (Session Layer ) - этот уровень обеспечивает стандартизацию начала и завершения сеансов связи между различными приложениями и сетевыми блоками.

7) Физический уровень (Physical Layer ) - этот уровень определяет стандарты физических характеристик устройств в сети, в том числе типы соединений и разъёмов, электрические характеристики кабелей, уровня напряжения, силы тока и тд.

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

Controller Area Network (CAN)

CAN был разработан Robert Bosch GmbH для автомобильной промышленности в начале 1980-х годов и официально публично выпущен в пользование в 1986 году. Эта разработка CAN от Bosch была принята в качестве стандарта ISO (ISO 11898 ), в 1993 переименована в CAN 2.0A , и расширена в 1995 году, чтобы позволить идентифицировать большее количество сетевых устройств в CAN 2.0B . Как правило, CAN шина соединяет в сеть модули (или узлы), используя два провода, витая пара. Многие компании и не только автомобильные, внедряют CAN протокол в свои разработки для взаимосвязи различных электронно-управляемых устройств. В неофициальной классификации устройства связанные протоколом CAN и имеющие процессоры серии MPC 5xx , называются TouCAN модули; имеющие процессоры серии MPC 55xx называются FlexCAN модули. CAN - последовательный, мульти-отправляющий, многоадресный протокол, это означает, что, когда шина свободна, любой узел, может отправить сообщение (мульти-отправляющее устройство), и все узлы могут получить и отреагировать на сообщение (многоадресно передано). Узел, который инициирует сообщение, называют передатчиком, любой узел не отправляющий сообщение называют получателем. Всем сообщениям присвоены статические приоритеты, передающий узел остаётся передатчиком до тех пор пока шина не станет неактивной или пока в сети не появилось сообщение от другого узла с более высоким приоритетом, процесс который определяет приоритет сообщений и называется - арбитраж. Сообщение по CAN шине может содержать до 8 байтов данных. Идентификатор сообщения описывает контент данных и используется получающими узлами для определения места назначения в сети (другими словами - адресата, узел которому это сообщение адресовано). В коротких сетях (≤ 40 м), скорость передачи сообщений может достигать до 1 Мбит/с. Более длинные сетевые расстояния уменьшают доступную скорость передачи, например до 125 Кбит/с в сети длиной до 500м. Высокоскоростной CAN (“ High speed” CAN ) сетью, считается сеть со скоростью передачи данных более 500 Кбит/с.

Основные принципы CAN

Детали спецификации CAN протокола полностью описаны в Robert Bosch GmbH , “ CAN Specification 2.0,” 1991 . Ознакомиться с документом в формате PDF можно последующему адресу http://esd.cs.ucr.edu/webres/can20.pdf . Далее я дам максимально возможно краткое описание того как данные передаются по CAN, как структурированы сообщения CAN и как обрабатываются ошибки передачи сообщений.

Есть четыре типа сообщений CAN , или фреймы (frames ): фрейм данных (Data Frame ), удаленный фрейм (Remote Frame ), ошибочный фрейм (Error Frame ) и фрейм перегрузки (Overload Frame ).

Data Frame - стандартное сообщение CAN, широковещательно передаваемые данные от передатчика на другие узлы сети.

Remote Frame -широковещательно передаваемое передатчиком сообщение, на запрос данных от конкретного узла сети.

Error Frame -может быть передан любым узлом, который обнаруживает ошибку в сети.

Overload Frame -используются как запрос на предоставление дополнительной паузы между получаемыми данными ( Data Frame ) или запросами на получение данных ( Remote Frame ).

Ниже проиллюстрированы различия между Data Frames для стандартов CAN 2.0A и CAN 2.0B,- рис. 2

Различие между форматами CAN 2.0 А и CAN 2.0B заключаются в том что фрейм данных для CAN 2.0B поддерживает как стандартный идентификатор фрейма данных - 11 бит, так и расширенный идентификатор фрейма данных - о 29 бит. Фреймы стандартного и расширенного формата могут без проблем передаваться по одной на той же шине, и даже иметь в цифровой форме эквивалентный идентификатор.

В этом случае у стандартного фрейма будет более высокий приоритет,- рис. 3

Описание фрейма сообщения стандарта CAN 2.0А

Начало сообщения (Start of Frame (SOF)

Идентификатор (Identifier ) - 11 бит, уникальный идентификатор, указывает приоритет.

Удаленный запрос на передачу () - 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения.

Резерв (Reserved ) - 2 бита, должны быть доминантными.

Длина кода данных (Data Length Code (DLC)

Поле передаваемых данных (Data Field DLC .

Cyclic Redundancy Check (CRC) ) - 15 бит.

Разделитель CRC

Подтверждение (Acknowledge (ACK)

Разделитель ACK - 1 бит, должен быть рецессивным.

Завершение сообщения (End of Frame (EOF) ) - 7 бит, должны быть рецессивными,- рис. 4

Описание фрейма сообщения стандарта CAN 2.0В

Начало сообщения ( Start of Frame (SOF) ) - 1 бит, должен быть доминантным.

Идентификатор стандартного и расширенного форматов ( Identifier ) - 11 бит, уникальный идентификатор, соответствует базовому ID в расширенном формате.

Идентификатор расширенного формата (Identifier – Extended Format ) - 29 бит, состоит из 11 бит базового ID и 18 бит расширенного ID .

Удаленный запрос на передачу (Remote Transmission Request (RTR) ) стандартный и расширенный форматы - 1 бит, доминантный в сообщении и рецессивный в запросе на передачу сообщения. В стандартном формате 11 бит идентификатора следуют за битом RTR .

Замещение удалённого запроса (Substitute Remote Request ( SRR ) ). Для расширенного формата - 1 бит, должен быть рецессивный. SRR передаются в расширенных форматах сообщений на позиции бита RTR в стандартном сообщении. В арбитраже между стандартными и расширенными сообщениями, рецессивные SRR обеспечивает приоритет стандартным сообщениям.

Поле IDE – для стандартного и расширенного форматов - 1 бит, должен быть рецессивным для расширенного формата и доминантным для стандартного.

Резерв (Reserved r0 ) для стандартного формата - 1 бит, должен быть доминантным.

Резерв (Reserved r1, r0 ) для расширенного формата - 2 бита, должны быть рецессивными.

Длина кода данных ( Data Length Code (DLC ) ) - 4 бита, количество байтов данных (0-8).

Поле передаваемых данных ( Data Field ) - от 0 до 8 байт, размер определен в поле DLC .

Контрольный циклический избыточный код ( Cyclic Redundancy Check (CRC ) ) - 15 бит.

Разделитель CRC - 1 бит, должен быть рецессивный.

Подтверждение (Acknowledge (ACK ) ) - 1 бит, передатчик отправляет рецессивный; получатель подтверждает доминантным.

Разделитель ACK - 1 бит, должен быть рецессивным.

Завершение сообщения ( End of Frame (EOF ) ) - 7 бит, должны быть рецессивными.

Фрейм данных CAN

Фрейм данных CAN состоит из семи полей: Начало фрейма ( SOF ), арбитраж, управление, данные, цикличные, проверка по избыточности (CRC) , подтверждение (ACK ) и конец фрейма (EOF ). Биты сообщения CAN обозначены как "доминирующие" (0) или "рецессивные" (1). Поле SOF состоит из одного доминирующего бита. Все сетевые узлы синхронно ожидают команды разрешения на передачу сообщений и начинают передавать одновременно. Арбитражная схема определяет, какой из узлов, пытающихся передавать сообщения имеет главный приоритет и фактически будет управлять шиной.

А рбитраж (Arbitration)

Арбитражное поле сообщения CAN состоит из 11-или 29-разрядного идентификатора и бита удаленной передачи ( RTR ). Арбитражную схему CAN называют “ носителем контроля с множественным доступом и обнаружением коллизий ” или CSMA/CD , которая гарантирует, что самое важное сообщение с наивысшим приоритетом будет передано по всей сети в первую очередь . Приоритет сообщения определен численным значением идентификатора в арбитражном поле, поле с самым низким численным значением имеет самый высокий приоритет. Неразрушающий, интеллектуальный арбитраж разрешает конфликты среди конкурирующих передатчиков. Это означает, что шина может считаться действующей как логический элемент И ( AND gate ). Если какой-либо узел пишет по сети доминантный признак (0), то каждый узел читает доминирующий бит независимо от его назначения, заданного передающим узлом. Каждый передающий узел всегда читает ответ на каждый переданный бит. Если узел передает рецессивный бит запроса на отправку сообщения и получает доминирующий бит для прочтения сообщения, он сразу же прекращает передавать.

Ниже проиллюстрирован приоритет сетевого арбитража где третий узел имеет высший приоритет и первый низший,- рис. 5

Бит RTR включён для того чтобы различать сообщения для передачи и удаленные запросы на приём сообщений. В стандартных сообщениях для передачи ( Data Frame ) бит RTR должен быть доминантным, а в удаленных запросах на приём сообщений ( Remote Frame ) должен быть быть рецессивным.

Контрольное поле и поле данных в сообщении (Control and Data Fields)

Поле управляющее длиной кода данных ( DLC ) состоит из 6 бит (из которых используются только 4 младших бита), они показывают количество данных в сообщении. Поскольку только до 8 байт данных может быть отправлено в одном сообщение, поле DLC может принимать значения в диапазоне от 000000 до 000111. Данные которые должны быть переданы содержатся только в поле данных. В первую очередь передается наиболее значимый байт ( M ost significant byte (MSB) ) из байтов данных.

Обработка ошибок (Error Handling)

В протоколе CAN реализовано пять уровней обнаружения ошибок. На уровне сообщений, выполняется циклическая проверка избыточности ( Cyclic Redundancy Check (CRC) ), проверки сообщения и обязательное подтверждение проверок ( Acknowledge (ACK) ). Бит проверки уровней состоит из монитора и наполнения.

Циклические ошибки избыточности обнаруживаются, используя код CRC размером 15 битов, вычисленный передатчиком из контента сообщения. Каждый получатель, принимающий сообщение, повторно вычисляет код CRC и сравнивает его с переданным значением. Несоответствие между этими двумя вычислениями заставляет установить флаг (flag ) ошибки. Проверяемые сообщения, в которых будет установлен флаг ошибки, это обнаружение получателем недопустимого бита в разделителе CRC , разделителе ACK , в завершении сообщения EOF или в 3-х битном разделяющим сообщения пространстве. В конечном итоге каждый принимающий узел записывает доминантный бит в ячейку разделителя ACK , которая затем читается отправившим это сообщение узлом. И если приём сообщения получателем не подтверждён (возможно потому что получающий узел перестал работать) то устанавливается флаг ошибки подтверждения ( ACK ).

На уровне битов мы уже отметили, что каждый переданный бит считывается снова передатчиком этого сообщения при контроле подтверждения о получении сообщения, присланного получателем. Если контролируемое значение отличается от отправленного, значит на уровне битов обнаружена ошибка. Дополнительно, ошибки на уровне битов обнаруживаются при помощи «вставок»: После пяти последовательных идентичных битов, которые передаются в сообщении следует «вставка», бит противоположной полярности вставляется передатчиком в поток передаваемых битов (биты «вставки» вставляются в сообщение от поля SOF до поля CRC ). Получатели автоматически проверяют сообщение на наличие «вставок». Если любой из принимающих узлов сети обнаруживает в полученном сообщении шесть последовательных идентичных битов, то фиксируется ошибка (отсутствия «вставки»). В дополнение для обнаружения ошибок, «вставки» гарантируют, что есть достаточно не нулевых окончаний в потоке битов ( non-return to zero (NRZ) ), чтобы поддержать синхронизацию.

Сообщение об ошибке (The CAN Error Frame)

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

Если количество зафиксированных ошибок в каждом буфере передачи или приёма соответствующего узла, больше чем нуль и меньше чем 128, узел считается «активным с ошибкой» (“ error active ” ), указывая на то, что несмотря что узел остается полностью функциональным, по крайней мере одна ошибка была обнаружена.

Если количество зафиксированных ошибок между 128 и 255, то узел переходит в «пассивный с ошибками» (“error passive” ) режим. В «пассивном с ошибками» режиме узел будет передавать на более медленном уровне, отправляя 8 рецессивных битов прежде чем снова отправить сообщение, распознав что шина свободна.

Если количество зафиксированных ошибок более 255, то узел переходит в режим «отключен от сети» (“ bus off ” ), отключив себя самостоятельно.

Ошибка при получении добавляет в общее количество учтённых ошибок 1, ошибка при передаче добавляет в общее количество учтённых ошибок 8. Последующие безошибочные сообщения постепенно уменьшают количество учтённых ошибок на 1, за каждое безошибочное сообщение. Если общее количество учтённых ошибок возвращается к нулю, узел возвращается в нормальный режим функционирования. Узел в находящийся режиме “ bus off ” может перейти в режим “ error active ” после 128 входов в сеть из 11 последовательных рецессивных битов, которые были проконтролированы. Сообщение считается безошибочным, если передающий узел не нашёл в нём ошибок вплоть до поля EOF . Повреждённые сообщения отсылаются повторно сразу как только шина становится свободной.

Запрос данных от конкретного узла сети (The CAN Remote Frame)

Узел, которому необходимы данные от другого узла сети, может запросить передачу таких данных, отправив соответствующий запрос на получение данных ( Remote Frame ). Например, микропроцессору управления центральным замком на вашем автомобиле необходимо знать положение селектора коробки передач от ЭБУ трансмиссии (является ли он в положении «паркинг»). Структура запроса на получение данных аналогична структуре стандартного сообщения только без поля данных ( data field ) и с рецессивным RTR битом.

Запрос на предоставление дополнительной паузы между получаемыми данными и свободное пространство между сообщениями (Overload Frames and Interframe Space)

Если какой-либо узел сети будет получать сообщения быстрее, чем он может их обработать, то будет сгенерирован запрос на предоставление дополнительной паузы между получаемыми данными ( Overload Frames )чтобы обеспечить дополнительное время между принимаемыми данными или запросами на получение сообщений ( Remote Frame ). Подобно сообщению об ошибке, Overload Frame имеет два поля с битами: flag перегрузки состоящий из шести доминирующих битов и разделитель перегрузки, состоящий из восьми рецессивных битов. В отличие от сообщений об ошибке, суммарный подсчёт Overload Frames не ведётся.

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

CAN обеспечивает устойчивое, простое и гибкое сетевое решение для производственных, автомобильных и многих других приложений. Главный недостаток протокола CAN - что задержка сообщения не является определённой (из-за существования Error Frame s , Overload Frame s и повторных передач), и увеличения задержки ведёт к увеличению сетевого трафика. В целом использование шины не должно превышать 30% от максимальной мощности шины и гарантировать, что низкоприоритетные сообщения не испытывают недопустимую задержку. Использование шины определено как деление двух величин - общее количество использованных для передачи битов поделённое на общее максимально доступное количество для передачи битов , и вычисляется следующим образом:

Шаг 1 - Выбирается единица времени ≥ самого медленное зафиксированного периодического сообщение в сети (обычно 1 секунда).

Шаг 2 - Определяются все периодические сообщения.

Шаг 3 - К каждому из этих сообщений приблизительно одинакового размера, добавляются 47 служебных бит (размер служебных полей данных - SOF + Arbitration + RTR + Control + CRC + Acknowledgment + EOF +

Interframe Space = 1 + 11 + 1 + 6 + 16 + 2 + 7 + 3 = 47 bits).

Шаг 4 - Рассчитывается количество бит используемых в сообщениях путем умножения размера сообщения в битах на количество передач выполняемых в единицу времени.

Шаг 5 - Суммирование всех битов используемых в переданных сообщениях для оценки общего объёма сетевого трафика. Умножение этой величины на страховочный коэффициент 1.1 для получения наихудшего прогноза сетевого трафика.

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

Протоколы синхронизированные по времени (Time-triggered Protocols)

Для контроля над сетью в реальном времени было бы желательно реализовать такой протокол связи, который гарантирует, что для сообщений выбираются крайние временные параметры независимо от нагрузки на шину. Пример такого протокола, который контролирует временной уровень связи CAN данных, это “ time-triggered CAN ,” или TTCAN (ISO 11898-4 ). TTCAN сообщения имеют два специальных типа, называемые «окна времени» ( time windows ): привилегированные окна времени ( exclusive time windows ), и арбитражные окна времени ( arbitrating time windows ). Еxclusive time windows прикреплены к специальным сообщениям, которые передаются периодически. Таким образом, Еxclusive time windows не конкурируют за доступ к шине. Аrbitrating time windows используются для сообщений не имеющих строгих ограничений по времени.

Аrbitrating time windows , как нормальные сообщения CAN , конкурируют за доступ к шине на основе приоритета через арбитраж. Тime-triggered CAN протокол, требует наличия в сети "главного узла" ( master node ), который периодически широковещательно передает сигнал времени сети (называемый глобальным временем ( global time )) в специальном информационном сообщении. Для повышения отказоустойчивости в сети должны быть несколько потенциальных главных узлов. Если главный узел перестал работать (обнаружено отсутствие специального информационного сообщения), другие потенциальные главные узлы конкурируют за статус «главного узла» при помощи арбитража и новым «главным узлом» становится узел с самым высоким приоритетом. После этого новый главный узел начинает широковещательно передавать специальные информационные сообщения - global time . Тime-triggered CAN протокол не ретранслирует повреждённые сообщения, и при этом это не вызывает Error Frames.

У протокола TTCAN есть конкурирующий протокол FlexRay , разработанный консорциумом автомобильных производителей и поставщиков. Коммуникационное сообщение (фрейм) FlexRay состоит из периодических синициированных "статических" и "динамических" частей. Статический сегмент составлен из одинаковой длины временных интервалов, соответствующих соединенным в сеть узлам. Каждый узел передает свои сообщения синхронно в его зарезервированном слоте. Статический сегмент также передает "синхронизирующий" кадр, чтобы обеспечить глобальную переменную ( timebase ) для сети. В отличие от CAN , нет никакого арбитража для шины. Динамический сегмент - по существу механизм "опроса" где каждому узлу дают возможность поместить инициированное событие или асинхронное сообщение в шину в порядке приоритетов, используя механизм синхронизации «миниразделения на слоты». Для повышения отказоустойчивости, узлы сети использующей протокол FlexRay , могут быть связаны двумя шинами или каналами одновременно.

Ну вот, в принципе, вся основная информация о протоколе CAN , а теперь немного о том, как выглядит CAN шина на примере автомобилей произведённых в Японии . Сразу хочу отметить, что без надлежащего диагностического оборудования проводить диагностику и ремонт неисправностей CAN шины можно в очень ограниченном диапазоне. Всё сведётся к проверке физической целостности проводов, проверки состояния соединительных разъёмов, проверки сопротивления проводки и Terminal resistor , проверки соответствующего уровня напряжения на CAN low и CAN high линиях. Применение в диагностике дилерского оборудования тоже лишь облегчит проверку и сузит круг поиска неисправности, с очень большой неохотой автопроизводители допускают контакт с программным обеспечением, своей интеллектуальной собственностью. В случае проблем на программном уровне возможно только перепрограммирование или замена соответствующего ЭБУ.

Пример CAN шины автомобиля Nissan 2007г.в. - Рис. 7

Сетевой интерфейс CAN (Controller Area Network) был разработан в 1987г. (версия 1.0) фирмами BOSCH и INTEL для создания бортовых мультипроцессорных систем реального времени. Последняя спецификация интерфейса 2.0, разработанная фирмой BOSCH в 1992г., является дополнением предыдущей версии. В международной организации по стандартизации зарегистрирован ISO 11898 (для высокоскоростных приложений) и ISO 11519-2 (для низкоскоростных приложений).

Принцип работы

CAN является высокоинтегрированным сетевым интерфейсом передачи данных со скоростью до 1 Мбит/сек. Устройства в CAN-системе соединяются по шине, состоящей из 3-х проводов (2 сигнальных и один общий) (см. рис.).

Сообщения данных, передаваемые из любого узла по CAN-шине, могут содержать от 1 до 8 байт. Каждое сообщение помечено идентификатором, который в сети является уникальным (например: "Нагрев до 240", "Отказ нагрева","Бункер загружен", и т.д.). При передаче другие узлы сети получают сообщение и каждый из них проверяет идентификатор. Если сообщение имеет отношение к данному узлу, то оно обрабатывается, в противном случае - игнорируется. CAN-контроллер каждого из устройств может обрабатывать одновременно несколько идентификаторов (например, контроллеры SIEMENS и INTEL могут обрабатывать до 15). Таким образом, в каждом из устройств можно легко организовать несколько "виртуальных" каналов обмена информацией с различными устройствами, включая каналы одновременного получения сообщений.

Рис. 1. Соединение устройств по CAN-шине

Идентификаторы

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

Физическая шина

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

Высокая надёжность

Для обеспечения безотказной работы в тяжёлых условиях по стандарту ISO11898 CAN-контроллер обеспечивает работу в сети в следующих случаях:

• любой из 3-х проводов в шине оборван,
• любой провод - закорочен на питание,
• любой провод - закорочен на общий провод.

При обрыве 2-х проводов часть функций основной системы может быть реализована в каждой из подсистем, созданных обрывом.

Сетевая гибкость и лёгкость расширения

Принятая в CAN-сети схема передачи сообщений обеспечивает большие возможности при создании, расширении и модернизации систем.

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

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

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

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

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

Приоритет CAN-сообщения определяется двоичным значением его идентификатора.

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

Рис. 2. Соединение устройств по CAN-шине

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

CAN содержит 5-ступенчатый механизм обнаружения ошибок:

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

Циклический контроль по избыточности (CRC)

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

Текущий контроль логического уровня битов

Любой передатчик автоматически контролирует и сравнивает фактический логический уровень битов на шине с уровнем, который он передает. Если уровни не совпадают, помечается ошибка логического уровня битов.

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

Контроль передаваемого поля битов

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

Контроль заполнения битов

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

Контроль сигнала "Подтверждение Приема"

Каждое переданное сообщение подтверждается приемником, и если этого не произошло, тогда устанавливается флаг ошибки подтверждения приема.

Флаг ошибки

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

С учетом действия всех механизмов контроля, реальное значение возникновения необнаруженной ошибки в CAN-системе - 10-11 .

Формат CAN-сообщения

Стандартный CAN-протокол (версия 2.0A) поддерживает формат сообщения с 11-разрядными идентификаторами (Стандартное сообщение).

Расширенный CAN-протокол (версия 2.0B) поддерживает 11-битовый и 29-битовый форматы идентификаторов (Расширенное сообщение).

Большинство контроллеров версии 2.0A передают и принимают только сообщения стандартного формата, хотя часть из них могут только получать сообщения расширенного формата.

Контроллеры версии 2.0B могут посылать и получать сообщения в обоих форматах.

Различия форматов

В версии 2.0B поле битов идентификатора состоит из двух частей.

Первая часть (основная часть идентификатора) имеет длину одиннадцать битов для совместимости с версией 2.0A, вторая часть - восемнадцать битов (расширение идентификатора), что дает общую длину идентификатора в двадцать девять бит.

Для различения форматов используются биты Identifier Extension (IDE) и Substitute Remote Request (SRR) в Поле Арбитража.

Многие сетевые протоколы описываются с помощью семиуровневой модели взаимодействия открытых систем OSI (Open System Interconnection ), как показано на Рис. 1 . Протокол CAN (Controller Area Network - контроллерная локальная сеть ) определяет канальный уровень (Data Link Layer ) и часть физического уровня (Physical Layer ). Оставшаяся часть физического уровня и все остальные вышележащие уровни не входят в спецификацию CAN и могут либо определяться разработчиком системы, либо реализовываться с помощью существующих высокоуровневых протоколов (Higher Layer Protocols - HLPs ) и физических уровней.

Как сказано выше, канальный уровень определяется спецификацией CAN. Подуровень управления логической связью (Logical Link Control - LLC ) обеспечивает управление перегрузкой и уведомление о ней, фильтрацию сообщений и функции управления восстановлением. Подуровень управления доступом к среде (Medium Access Control - MAC ) выполняет инкапсуляцию/декапсуляцию (расформирование) данных, обнаружение ошибок и защиту от них, битстаффинг/дестаффинг (битовое наполнение/удаление наполняющего бита), функции преобразования в последовательную форму и обратно.

Подуровни соединения с физической средой (Physical Medium Attachment - PMA ) и среда-зависимого интерфейса (Medium Dependent Interface - MDI ) - две части физического уровня, не определённые в CAN. Подуровень физической сигнализации (Physical Signaling - PS ), наоборот, определён в спецификации CAN. Разработчик может выбрать любой драйвер/приёмник и среду передачи, если они соответствуют требованиям PS-подуровня.

Международная организация по стандартизации (International Standards Organization - ISO ) определила стандарт, который включает спецификацию CAN в качестве физического уровня. Стандарт ISO-11898 изначально был создан для высокоскоростной связи в транспортных средствах, использующей CAN. ISO-11898 определяет физический уровень для обеспечения совместимости между приёмопередатчиками CAN.

Контроллер CAN обычно реализует всю спецификацию CAN аппаратно, как показано на Рис. 1 . PMA-подуровень не определяется CAN, однако, он определён в ISO-11898. Данный пример применения рассматривает приёмопередатчик CAN MCP2551 и то, насколько он удовлетворяет требованиям спецификации ISO-11898.

Рис. 1. CAN и модель OSI

Краткий обзор ISO11898-2

ISO11898 - международный стандарт для высокоскоростной связи CAN, применяемой в транспортных средствах. ISO-11898-2 определяет PMA и MDI подуровни физического уровня. Общее представления узлов и шины CAN, описанное в ISO-11898 приведено на Рис. 3 .

Уровни шины

CAN определяет два логических состояния: рецессивное (recessive ) и доминантное (dominant ). ISO-11898 определяет дифференциальное напряжение для представления рецессивного и доминантного состояний (или битов), как показано на Рис. 2 .

В рецессивном состоянии (то есть логическая "1" на входе TXD MCP2551) дифференциальное напряжение на CANH и CANL меньше минимального порог (Рис. 4).

В доминантном состоянии (то есть логический "0" на входе TXD MCP2551) дифференциальное напряжение на CANH и CANL больше минимального порога. Доминантный бит перекрывает рецессивный бит на шине для достижения неразрушающего поразрядного арбитража.

Рис. 2. Дифференциальная шина

Разъёмы и провода

В ISO-11898-2 не определены механические провода и разъёмы. Однако спецификация требует, чтобы провода и разъёмы соответствовали электротехническим требованиям.

Спецификация также требует наличие резисторов-терминаторов номиналом 120 Ом на каждом конце шины. На Рис. 3 показан пример шины CAN, основанной на ISO-11898.

Рис. 3. Шина CAN

Рис. 4. Номинальные уровни шины по ISO-11898

Помехоустойчивость

Спецификация ISO11898-2 требует, чтобы приёмопередатчик, соответствующий спецификации или совместимый с ней, соответствовал ряду электротехнических требований. Некоторые из этих требований предусмотрены, чтобы гарантировать, что приёмопередатчик сможет выдержать жёсткие электрические условия, таким образом защищая узел CAN. Входы приёмопередатчика должны выдерживать напряжение от -3 В до +32 В и кратковременное воздействие напряжения от -150 В до +100 В. Таблица 1 показывает главные электрические требования ISO11898-2 в сравнении со спецификацией MCP2551.

Таблица 1. Сравнение спецификаций MCP2551 и ISO11898-2.

Параметр	ISO-11898-4		MCP2551		Единица измерения	Комментарии
	минимум	максимум	минимум	максимум
Постоянное напряжение на CANH и CANL	-3	+32	-40	+40	В	Превышает ISO-11898
Кратковременное воздействие напряжений на CANH и CANL	-150	+100	-250	+250	В	Превышает ISO-11898
Напряжение синфазного сигнала шины	-2.0	+7.0	-12	+12	В	Превышает ISO-11898
Выходное напряжение шины в рецессивном состоянии	+2.0	+3.0	+2.0	+3.0	В	Соответствует ISO-11898
Дифференциальное выходное напряжение рецессивного состояния	-500	+50	-500	+50	мВ	Соответствует ISO-11898
Внутреннее сопротивление	10	100	20	100	кОм	Соответствует ISO-11898
Входное сопротивление	5.0	50	5.0	50	кОм	Соответствует ISO-11898
Дифференциальное выходное напряжение доминантного состояния	+1.5	+3.0	+1.5	+3.0	В	Соответствует ISO-11898
Выходное напряжение доминантного состояния на CANH	+2.75	+4.50	+2.75	+4.50	В	Соответствует ISO-11898
Выходное напряжение доминантного состояния на CANL	+0.50	+2.25	+0.50	+2.25	В	Соответствует ISO-11898
Обнаружение постоянного доминанта (драйвер)	Не требуется		1.25	-	мс
Сброс при включении питания (POR) и обнаружение кратковременного падения напряжения (BOD)	Не требуется		Да		-

Длина шины

ISO11898 определяет, что приёмопередатчик должен быть способен управлять шиной длиной 40 м на скорости 1 Мбит/с. Большая длина шины достигается при уменьшении скорости передачи данных. Самое большое ограничение на длину шины накладывает задержка распространения приёмопередатчика.

Задержка распространения

Протокол CAN определяет рецессивное (логическая "1") и доминантное (логический "0") состояния для реализации схемы поразрядного неразрушающего арбитража. Именно на эту методологию арбитража больше всего воздействуют задержки распространения. Каждый узел, вовлечённый в арбитраж, должен быть способен осуществлять выборку уровня каждого бита в пределах одного и того же времени передачи бита. Например, если два узла на противоположных концах шины начали передавать сообщения в одно и то же время, они должны выполнить арбитраж для захвата управления шиной. Арбитраж будет эффективен, только если оба узла способны сделать выборку в течение одного и того же времени передачи бита. На Рис. 5 показана односторонняя задержка распространения между двумя узлами. Чрезмерные задержки распространения (вне точки выборки) приведут к ошибочному арбитражу. Это означает, что длина шины ограничена для заданной скорости передачи данных.

Задержка распространения в системе CAN вычисляется как удвоенная сумма времени прохождения сигнала по физической шине туда и обратно (t BUS ), выходной задержки драйвера (t DRV ) и входной задержки компаратора (t CMP ). Приняв, что все узлы в системе имеют одинаковые задержки компонентов, получим задержку распространения:

t PROP = 2·(t BUS + t CMP + t DRV ).

Рис. 5. Односторонняя задержка распространения

MCP2551 - приёмопередатчик CAN

Микросхема MCP2551 - приёмопередатчик CAN, который реализует физический уровень, описанный в спецификации ISO-11898-2. Он поддерживает скорость передачи данных до 1 Мбит/с и подходит для систем с напряжениями питания 12 В и 24 В. MCP2551 обеспечивает защиту от короткого замыкания до ±40 В и защиту от кратковременных напряжений до ±250 В.

Дополнительно, будучи совместим с ISO-11898-2, MCP2551 обеспечивает сброс при включении питания (power-on reset - POR ) и защиту от кратковременного падения напряжения (brown-out protection ), а также обнаружение постоянного доминанта (permanent dominant detection ), чтобы гарантировать, что обесточенный или неисправный узел не будет мешать работе шины. Устройство реализует настраиваемую наклонную регулировку усиления (slope control ) на выводах шины для уменьшения излучения радиопомех (RFI ). На Рис. 6 представлена блок-схема MCP2551.

Рис. 6. Блок-схема MCP2551

Основная работа MCP2551

Передача

Контроллер протокола CAN выдаёт поток последовательных данных на логический вход TXD MCP2551. Соответствующее рецессивное или доминантное состояние выдаётся на выводы CANH и CANL.

Приём

MCP2551 принимает доминантное или рецессивное состояния на те же выводы CANH и CANL, с которых осуществляется передача. Эти состояния выдаются в виде соответствующих логических уровней на вывод RXD, чтобы контроллер протокола CAN принял кадр CAN.

Рецессивное состояние

Логическая "1" на входе TXD отключает драйверы от вводов CANH и CANL, и выводы "подтягиваются" к номиналу 2.5 В через резисторы смещения.

Доминантное состояние

Логический "0" на входе TXD включает драйверы выводов CANH и CANL. На CANH подаётся на ~1 В больше, чем номинал рецессивного состояния 2.5 В, таким образом увеличивая напряжение до ~3.5 В. На CANL подаётся на ~1 В меньше, чем номинал рецессивного состояния, таким образом уменьшая напряжение до ~1.5 В.

Режимы работы

Существует три режима работы, которые управляются извне через вывод RS:
1. Высокоскоростной режим.
2. Режим наклонной регулировки усиления.
3. Режим ожидания (Standby )

Высокоскоростной режим

Высокоскоростной режим выбирается подключением вывода RS к V SS . В этом режиме выходные драйверы имеют быстрое время нарастания и спада, что обеспечивает наивысшие скорости передачи до 1 Мбита/с и/или максимальную длину шины, а также обеспечивая минимальные циклические задержки приёмопередатчика.

Режим наклонной регулировки усиления

Если требуется уменьшить излучаемые драйвером электромагнитные помехи, MCP2551 можно установить в режим наклонной регулировки усиления подключением резистора (R EXT) от вывода RS на общий минус. В режиме наклонной регулировки усиления скорость нарастания выходного напряжения на одном проводе (на CANH или CANL) в основном пропорциональна выходному току на выводе RS. Ток должен быть в диапазоне от 10 мкА Уменьшение скорости нарастания выходного напряжения приводит к уменьшению скорости передачи данных CAN при заданной длине шины, либо к сокращению длины шины при заданной скорости передачи данных.

Режим ожидания

Режим ожидания (или спящий режим (sleep )) устанавливается подключением вывода RS к V DD . В спящем режиме передатчик отключен, а приёмник работает в режиме пониженного энергопотребления. Принимающий вывод (RXD) по-прежнему функционирует, но на более низкой скорости.

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

Обнаружение постоянного доминанта на передатчике

Если на передатчике обнаруживается состояние постоянного доминанта, MCP2551 отключает передатчик от CANH и CANL. Эта возможность предотвращает постоянное разрушение шины CAN неисправным узлом (контроллером CAN или самим MCP2551).

Драйверы отключаются, если низкий уровень присутствует на TXD в течение более чем ~1.25 мс (минимум) (см. Рис. 7).

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

Рис. 7. Обнаружение постоянного доминанта на TXD

Сброс при включении питания и защита от кратковременного снижения питания

MCP2551 имеет способность сброса при включении питания (Power-On Reset - POR ) и обнаружения кратковременного снижения напряжения питания (Brown-Out Detection - BOD ) (см. Рис. 8 ).

Сброс при включении питания (POR)

Когда на MCP2551 подаётся питание, выводы CANH и CANL остаются в высокоимпедансном состоянии до тех пор, пока VDD не достигнет высокого напряжения POR (POR high voltage - VPORH ). Кроме того, если при включении питания на выводе TXD низкий уровень, выводы CANH и CANL остаются в высокоимпедансном состоянии до тех пор, пока на TXD не установится высокий уровень. После чего драйвер будет функционировать нормально.

Обнаружение кратковременного снижения напряжения питания (BOD)

BOD происходит, когда VDD опускается ниже низкого напряжения сброса при включении питания (power-on reset low voltage - VPORL ). В этой точке выводы CANH и CANL входят в высокоимпедансное состояние и остаются в нем, пока не будет достигнуто напряжение VPORH.

Рис. 8. Сброс при включении питания и обнаружение кратковременного снижения напряжения питания

Смещения земли

Поскольку не требуется обеспечивать общую землю между узлами, то возможно возникновение смещений земли между ними. То есть каждый узел может наблюдать разные однопроводные напряжения шины (напряжения синфазного сигнала шины), в то же время поддерживая одинаковое дифференциальное напряжение. В то время как MCP2551 предусмотрен для управления смещениями земли от -12 В до +12 В, спецификация ISO-11898 требует только от -2 В до +7 В. На Рис. 9 и 10 показано, как между узлами возникают смещения земли.

Рис. 9 показывает передающий узел с положительным смещением земли относительно принимающего узла. Приёмник MCP2551 может работать с CANH = +12 В. Максимальное выходное напряжение доминанта CAN (V O(CANH)) от передающего узла составляет 4.5 В. Вычитание этого максимума даёт смещение земли (относительно принимающего узла) в 7.5 В для передающего узла. В рецессивном состоянии каждый узел пытается притянуть выводы CANH и CANL к их основным уровням (обычно 2.5 В). Однако результирующее напряжение синфазного сигнала в рецессивном состоянии принимает значение 6.25 В для принимающего узла и -1.25 В для передающего.

Рис. 10 показывает передающий узел с отрицательным смещением земли относительно принимающего узла. Приёмник MCP2551 может работать с CANL = -12 В. Минимальное выходное напряжение доминанта CAN (V O(CANL)) из передающего узла составляет 0.5 В. Вычитание этого минимума даёт фактическое смещение земли относительно принимающего узла в -12.5 В. Напряжение синфазного сигнала для рецессивного состояния составляет -6.25 В для принимающего узла и 6.25 В для передающего.

Поскольку все узлы работают как передатчики для части каждого сообщения (то есть каждый приёмник должен подтверждать (ACK) правильные сообщения в течение временного интервала ACK), наибольшее смещение земли, допускаемое между узлами составляет 7.5 В, как показано на Рис. 9 .

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

Рис. 9. Земля принимающего узла ниже земли передающего

Рис. 10. Земля принимающего узла выше земли передающего

Оконечная нагрузка шины

) используется для минимизации отражения сигнала в шине. ISO-11898 требует, чтобы шина CAN имела номинальную характеристику входного полного сопротивления линии передачи в 120 Ом. Поэтому обычное значение согласующего резистора для каждого конца шины составляет 120 Ом. Есть несколько различных способов реализации оконечной нагрузки, используемых для увеличения электромагнитной совместимости (EMC ) (см. Рис. 11 ):

1. Стандартная оконечная нагрузка.
2. Разделённая оконечная нагрузка.
3. Смещённая разделённая оконечная нагрузка.

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

Стандартная оконечная нагрузка

Как подразумевает название, эта оконечная нагрузка состоит из одинарных резисторов номиналом в 120 Ом на каждом конце шины. Этот метод приемлем во многих системах CAN.

Разделённая оконечная нагрузка

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

Смещённая разделённая оконечная нагрузка

Этот метод оконечной нагрузки используется для поддержания синфазного напряжения рецессивного сигнала на постоянном значении, таким образом увеличивая EMC. Эта схема аналогична схеме разделённой оконечной нагрузки, но добавлена дополнительная схема делителя напряжения для достижения напряжения V DD /2 между двумя резисторами по 60 Ом (см. Рис. 11 ).

Примечание : Номиналы резисторов смещения на Рис. 11 , также как и резисторов разделённой оконечной нагрузки, должны как можно меньше отличаться друг от друга.

Рис. 11. Схемы оконечной нагрузки