Ошибка передачи начала кадра сообщения

Ошибка передачи начала кадра сообщения

Протокол CAN. Описание, формат кадра, контроль ошибок.

Приветствую всех на нашем сайте! Сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…

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

Основные характеристики протокола CAN:

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

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

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

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

В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.

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

Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети!

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

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

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

Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).

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

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

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

Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:

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

Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.

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

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

Кадр перегрузки (overload frame) используется очень редко… Его идея и назначение заключается в том, что с его помощью устройство, которое в данный момент не может принять данные, запрашивает повторную передачу этих же данных.

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

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

Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN! Стандарт предусматривает несколько механизмов контроля ошибок.

• Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
• Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
• Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
• Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.

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

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

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

• Error Active
• Error Passive
• Bus Off

Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:

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

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

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

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

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

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

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

Источник

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

Например, при передаче двух сообщений «abrakadabra» подряд возможно, что оно будет передано с ошибкой описанного вида, и тогда будет получено сообщение вида «abrakadabrabrakadabra» или «abrakadabrakadabra» (в первом случае совмещение произошло по одному символу, а во втором — по четырем).

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

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

Входные данные
В единственной строке выходных данных следует непустая строка t, состоящая из строчных букв латинского алфавита. Длина строки t не превосходит 100 символов.

Выходные данные
Если сообщение t не может содержать ошибки, выведите «NO» (без кавычек) в единственную строку выходных данных.

В противном случае в первой строке выведите «YES» (без кавычек), а в следующей строке выведите строку s — возможное сообщение, которое могло привести к ошибке. Если возможных ответов несколько, разрешается вывести любой из них.

Примеры

входные данные
abrakadabrabrakadabra
выходные данные
YES
abrakadabra

входные данные
acacacaca
выходные данные
YES
acaca

входные данные
abcabc
выходные данные
NO

входные данные
abababab
выходные данные
YES
ababab

входные данные
tatbt
выходные данные
NO

Примечание
Во втором примере подходящим ответом также является строка acacaca.
С чего начинать подскажите пожалуйста.

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

   Каждое сообщение, передаваемое по шине, состоит из 7 частей. CANПоддержка протоколаЕдинственная разница между двумя форматами сообщенийидентификаторДлина (ID) другая, стандартный формат 11 бит, расширенный формат 29 бит.

   В стандартном форматеПакетыНачальный бит называется началом кадра (SOF), за которым следует поле арбитража, состоящее из 11-битного идентификатора и бита запроса удаленной передачи (RTR). Бит RTR указывает даФрейм данныхЭто все еще кадр запроса, и в кадре запроса нет байтов данных.

   Поле управления включает в себя бит расширения идентификатора (IDE), указывающий, является ли это стандартным форматом или расширенным форматом. Он также включает зарезервированный бит (ro) для будущего расширения. Последние четыре бита используются для указания длины данных в поле данных (DLC). Диапазон полей данных составляет от 0 до 8 байтов.Циклическая проверка избыточности(CRC）。

   Поле подтверждения (ACK) состоит из битов подтверждения и разделителей подтверждения. Два бита, отправленные отправляющей станцией, являются рецессивными уровнями (логика 1). В это время принимающая станция, которая правильно отправляет сообщение, получает главный уровень (логика 0) для его покрытия. Таким образом, отправляющая станция может гарантировать, что по крайней мере одна станция в сети сможет правильно принять сообщение.

   ПакетыХвост отмечен концом кадра. Между двумя соседними сообщениями существует короткий интервал: если в это время ни одна станция не обращается к шине, она будет свободна.

   Как показано на фиг.11, конкретная цифра или цифры будут подробно описаны ниже.

   

   Рисунок 11 Структура сообщения по шине CAN

2. Фрейм данных

   Кадр данных является наиболее часто используемым и состоит из 7 сегментов в структуре, среди которых, согласно длине кода идентификатора арбитражного сегмента, он делится на стандартный кадр (CAN2.0A) и расширенный кадр (CAN2.0B).

   Кадр данных состоит из: начала кадра, арбитражного прерывания, конца управления, сегмента данных, сегмента CRC, сегмента ACK и конца кадра.

   Как показано на рисунке 21 (конкретная структура кадра будет подробно описана ниже).

   

   Рисунок 2–1 Тип и структура фрейма данных

3. Начало кадра и конец кадра

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

   Конец кадра: состоит из 7 последовательных невидимых битов.

   (Примечание. Доминирующий и рецессивный уровни — это дифференциальные уровни сигналов относительно CAN_H и CAN_L, а не высокие и низкие уровни на уровне TTL, что требует внимания.) См. Рисунок 2-2.

   

   Рисунок 2–2 Начало и конец кадра

4. Арбитражный раздел

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

   CAN-шина не определяет приоритет узла, но указывает приоритет кадра данных через идентификатор кадра сегмента арбитража. Согласно различным версиям стандарта CAN2.0, идентификатор кадра делится на 11 и 29 бит. Как показано на рисунке 23

   

   Рисунок 2–3 Структура фрейма данных

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

   

   Рисунок 2–4 Арбитраж

   Предположим, что все узлы A, B и C отправляют кадры одного и того же формата и типа, такие как кадры данных стандартного формата. Процесс состязания за шину показан на рисунке 16:

   

   Рисунок 2-5 Арбитражный механизм

   Из этого процесса анализа сделан вывод, что чем меньше значение идентификатора кадра, тем выше приоритет;

   То же самое относится к случаю того же кадра данных расширенного формата, удаленного кадра стандартного формата и удаленного кадра расширенного формата.

5. Контрольная секция

   Секция управления состоит из 6 битов. Секция управления стандартного кадра состоит из IDE флага расширенного кадра, зарезервированного бита r0 и кода DLC длины данных. Секция управления расширенного кадра состоит из IDE, r1, r0 и DLC, как показано на рисунке 17.

   

   Рисунок 2–6 Структура фрейма данных

6. Сегмент данных

   Объем данных, передаваемых в одном фрейме данных, составляет 0–8 байт. Такая структура короткого фрейма делает шину CAN в режиме реального времени, что очень подходит для автомобильных и промышленных приложений управления, как показано на рисунке 27.

   

   Рисунок 2–7 Сегмент данных

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

7. CRC сегмент

   CAN-шина использует проверку CRC для обнаружения ошибок данных. Значение проверки CRC сохраняется в сегменте CRC. Раздел проверки CRC состоит из 15-битного значения CRC и 1-битного ограничителя CRC, как показано на рисунке 28.

   

   Рисунок 2–8 Сегмент CRC

8. ACK сегмент

   Когда содержимое между началом кадра, полученного принимающим узлом, и сегментом CRC не содержит ошибок, он отправит доминирующий уровень в сегменте ACK, как показано на рисунке 29.

   

   Рисунок 2–9 Сегмент ACK

9. Дистанционная рамка

   По сравнению с фреймом данных в структуре удаленного фрейма нет сегмента данных, который состоит из 6 сегментов. Аналогично, он делится на стандартный формат и расширенный формат, а бит RTR равен 1 (рецессивный уровень), как показано на рисунке 31.

   

   Рисунок 3–1 Структура удаленного кадра

   Как показано на рисунке ниже, поскольку бит RTR кадра данных является доминирующим, бит RTR удаленного кадра является рецессивным.

   Поэтому, когда формат кадра и идентификатор кадра одинаковы, приоритет кадра данных выше, чем у удаленного кадра, как показано на рисунке 32:

   

   Рисунок 3–2 Механизм передачи данных между кадрами и удаленными кадрами

   

   Рисунок 3–3 Сравнение удаленных кадров данных кадров

   Разница между фреймом данных и удаленным фреймом показана на рисунке 33.

10. Ошибка кадра

    Хотя CAN-шина является высоконадежной шиной, ошибки все же могут возникать, существует пять типов ошибок CAN-шины (см. Рисунок 41).

    

    Рисунок 4–1 Тип ошибки кадра

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

    

    Рисунок 4–2 Структура уровня кадра ошибки

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

    

    Рисунок 4–3 Механизм обработки ошибок

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

11. Перегрузка кадра и интервала кадра

12. Рамка перегрузки

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

    

    Рисунок 5–1 Структура перегрузочной рамы

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

    

    Рисунок 5–2. Специфическая структура рамы перегрузки

13. Интервал кадра

    Интервал кадра используется для отделения данных или удаленных кадров от их предыдущих кадров, но интервал кадра не вставляется до кадров перегрузки и ошибок.

    

    По истечении интервала кадра, если ни один узел не отправляет кадр, шина переходит в режим ожидания.

    

    По истечении интервала кадра, если узел пассивной ошибки хочет отправить кадр, он сначала отправит 8 задержек передачи из-за рецессивного уровня перед отправкой кадра.

    

14. Общий процесс передачи по шине CAN

    Процесс обработки данных на канальном уровне шины CAN показан на рисунке 61:

    

    Рисунок 6–1 Общий процесс шины CAN

15. справочный материал

    «Базовое учебное пособие по полевой шине CAN-BUS на основе проекта — Чжоу Лигун, Хуан Сяоцин».

    «Технология Fieldbus и ее применение, второе издание, издательство Tsinghua University Press».