1.3 Типы сообщений сети can

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

• Data Frame (фрейм данных),

• Remote Frame (удаленный фрейм),

• Error Frame (фрейм ошибки),

• Overload Frame (фрейм перегрузки).

Data Frame (фрейм данных) – это наиболее часто используемый тип сообщения. Он перемещает данные с передатчика на приемник (приемники). Этот кадр сообщения состоит из семи основных полей (рисунок 1.2). Протокол CAN поддерживает два формата кадров сообщений, которые различаются только длиной идентификатора (ID). В стандартном формате его длина составляет 11 бит (спецификация CAN 2.0A), в расширенном – 29 (спецификация CAN 2.0B).

а) б)

Рисунок 1.2 – Фрейм данных стандартного (а) и расширенного (б) форматов

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

1. Поле SOF (Start of Frame – стартовый бит «начало кадра») находится в начале фрейма и содержит один доминирующий бит.

2. Поле арбитража (Arbitration Field) содержит 11- или 29-битовый идентификатор и RTR-бит (Remote Transmission Request), показывающий, является данный фрейм фреймом данных или удаленным фреймом (фреймом запроса, в котором отсутствует поле данных).

3. Управляющее поле (Control Field) содержит бит расширения идентификатора (IDE – identifier extension), который указывает тип формата кадра – стандартный или расширенный. Кроме того, в этом поле находятся зарезервированный для будущего применения бит RO и четыре бита DLC (Data Length Code) для указания длины поля данных.

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

5. Поле СRC обеспечивает механизм избыточного контроля по четности передаваемых данных (используется для определения ошибок).

6. Поле подтверждения ACK (Acknowledgement Field) (рисунок 1.3) состоит из области ACK (ACK Slot) в 1 бит и ограничителя поля ACK Delimiter и выполняет следующую функцию. ACK Slot помещается на шину передатчиком как рецессивный (логическая 1), а приемники, корректно принявшие данные, переписывают его в логический 0, делая его доминантным. Таким образом, передающий узел получает подтверждение, что хотя бы один приемник правильно принял его сообщение, и повтор не требуется. Сообщения подтверждаются приемниками независимо от результата тестирования данных при приёме.

Рисунок 1.3 – Поле подтверждения фрейма данных

7. Поле конца фрейма (EOF – End of Frame) содержится в фрейме данных и удаленном фрейме и состоит из семи рецессивных битов. После конца сообщения идет пауза. Длина паузы равна минимальному количеству битов, отделяющих последовательные сообщения. Если в этот момент ни одна из станций не выдает запрос на доступ к шине, то шина остается незанятой.

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

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

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