CAN – Controller Area Network

Views: 1106

Controller Area Network (CAN) первоначально был создан немецким поставщиком автомобильных систем Робертом Бош в середины 1980-х для автомобильной промышленности как метод для обеспечения возможности надежной последовательной связи. Целью было сделать автомобили более надежными, безопасными и экономичными при снижении веса жгутов проводов и их сложности. С момента своего создания, протокол CAN приобрел широкую популярность в области промышленной автоматизации и для грузовых автомобильных приложений. Другие рынки, где сетевые решения могут принести привлекательные преимущества, это медицинское оборудование, контрольно-измерительные приборы и мобильное оборудование также начинают использовать преимущества CAN. Цель этой статьи, чтобы объяснить некоторые из основ CAN и показать преимущества выбора CAN для сетевых приложений встраиваемых систем.

Обзор CAN

Большинство сетевых приложений нуждаются в многоуровневом подходе к реализации системы. Этот системный подход обеспечивает взаимодействие между продуктами разных производителей. Стандарт был создан международной организацией по стандартизации (ISO) в качестве шаблона для создания многоуровневого подхода. Она называется ISO взаимодействие открытых систем (OSI) Сеть многоуровнего формирования ориентировочная модель показана на рисунке 1 для справки.

Сам протокол CAN реализует большую часть двух нижних уровней этой эталонной модели. Часть среды коммуникационной модели были намеренно исключены из Bosch CAN спецификации, чтобы позволить разработчикам систем для адаптации и оптимизации протокола связи реализации его на носителях различных типов для максимальной гибкости (витая пара, одиночный провод оптически изолированный, РФ ИК и т.д.) . Благодаря такой гибкости однако, приходит проблема совместимости.

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

Основы CAN протокола

Связь на основе CAN протокола является CSMA/CD протоколом. CSMA отвечает за коллективный доступ к шине. Это означает, что каждый узел работающий в сети должен контролировать шину после последнего обращения к ней, прежде чем пытаться отправить сообщение в шину (Контроль Несущей). Кроме того, когда условие отсутствия активности определено, каждый узел на шине имеет равные возможности для передачи сообщения (коллективный доступ – CD). CD отвечает за обнаружение коллизий на шине. Если два узла в сети начинают передачу одновременно, узлы обнаруживают ‘столкновение’ и принимают соответствующие меры. В протоколе CAN используется неразрушающий метод поразрядного арбитража. Это означает, что сообщения остаются нетронутыми после завершении арбитража, даже если конфликт обнаружен. Весь этот арбитраж происходит без коррупции и задержки с узлом с имеющий более высокий приоритет сообщений.

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

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

Базовые сообщения связи.

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

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

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

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

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

Описание кадров

CAN протокол определяет четыре различных типа сообщений (или кадров):

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

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

Арбитражные поля позволяют установить приоритеты для сообщений на шине. Поскольку протокол CAN на основании свойства о доминирующем условии, логический определяет механизм арбитража, чем меньше число в арбитражном поле, тем выше приоритет сообщение имеет на шине. Арбитражный поле состоит из 12 бит (11 бит идентификатор и один RTR бит) или 32 бита (29 битный идентификатор, IDE бит для определения сообщение как длительного кадра данных, в SRR бит который не используется, и RTR бит), в зависимости от того, были ли использованы стандартные кадры или расширенные кадры. Только версия спецификации CAN 2.0B, определяет 29-битные идентификаторы и называет их расширенные кадры. Предыдущие версии спецификации CAN определяется 11-битные идентификаторы, которые называются стандартные кадры.

Как описано в предыдущем разделе, Дистанционный запрос на передачу (RTR=1) используется узлом, когда он требует, чтобы информация была направлена к нему от другого узла. Бит RTR=1 – дистанционный запрос отправляется с идентификатором какие данные требуются. RTR бит в Арбитражном поле используется, чтобы различать кадр дистанционного запроса и кадра данных. Если бит RTR является рецессивным (равен 1), то сообщение является дистанционным запросом. Если бит RTR является доминирующим (равен 0), сообщение – кадр данных.

Поле управления состоит из шести битов. Старший является бит IDE (означает расширенный кадр), который должен быть доминирующим (0) для стандартных кадров данных. Этот бит определяет, является ли сообщение стандартным или расширенным кадром. В расширенных кадрах, бит RB0 и RB1 зарезервированы. Четыре младших разрядов являются битами кода длины данных (DLC). Эти биты определяют длину данных, т.е. сколько байтов данных включены в сообщение. Следует отметить, что команды дистанционного запроса и не имеет поле данных, независимо от значения DLC битов.

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

рисунок 1

рисунок 2

Поле подтверждения – предназначено для контроля, что сообщение было правильно принято. Любой узел, который правильно получил сообщение, независимо от того, сколько узлов принимает или отбрасывает данные, формирует доминирующий бит на шине в слоте бита ACK (см. рисунок 1 или рисунок 2).

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

Быстрая и надежная связь
Поскольку CAN был первоначально разработан для использования для работы в автомобиле, и чтобы получить признание на рынке, критическим условием использования которого была задача эффективности в обработки ошибок. С выпуском версии 2.0B спецификации CAN, максимальная скорость передачи данных была увеличена в 8x раз по сравнению с версией 1.0 и составила 1Mbit/sec. При таких скоростях, даже самые критичные ко времени параметры могут быть переданы последовательно без проблем задержки. В дополнение к этому, протокол CAN имеет полный список ошибок которые он может определить, что обеспечивает целостность сообщений.

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

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

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

CRC ошибка

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

Ошибка подтверждения (ACK)

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

Ошибка Формы

Если узел обнаруживает доминирующей бит в одном из следующих четырех сегментах сообщения:

• конец кадра
• меж кадровое пространство
• бит подтверждения
• CRC Разделитель

протокол CAN определяет это как нарушение кадра и формирует кадр ошибки. Оригинальное сообщение затем передается после определенной паузы. (см. рисунок 1 и рисунок 2 для того, где эти сегменты лежат в сообщении CAN).

Бит ошибки

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

Разные ошибки

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

продолжение следует …

Это может быть интересно