Интерфейс CAN в ZETSENSOR

Документ описывает новый протокол, по которому взаимодействуют между собой цифровые модули ZETSENSOR, работающие по интерфейсу CAN 2.0 (начиная с версии 600 и выше).

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

Каждому участнику одной сети CAN назначается уникальный адрес узла — целое число в диапазоне от 1 до 63.
Цифровые модули ZETSENSOR поддерживают три скорости передачи данных:

• 100 кбит/с;
• 300 кбит/с;
• 960 кбит/с (или 1 Мбит/с для простоты).

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

Точка сэмплирования бита (Sample point) — в диапазоне от 60% до 85%.

Новый протокол разработан с целью решения ряда проблем старого протокола:

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

Для этого в новый протокол вводятся следующие основные изменения:

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

Основной упор в новом протоколе делается на арбитраж — встроенный в CAN 2.0 механизм разрешения коллизий. Арбитраж делает целесообразным использование расширенных идентификаторов, а также позволяет четко задавать приоритеты кадрам в зависимости от типа передаваемой ими информации.

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

Базовый и расширенный идентификаторы участвуют в механизме разрешения коллизий CAN — при одновременной отправке кадров несколькими узлами будет передан кадр с наименьшим значением идентификатора.

Базовый идентификатор состоит из одиннадцати битов:

• старшие три бита — базовый тип кадра;
• следующий бит — всегда нулевой;
• следующий бит — нулевой или четность;
• младшие шесть битов — адрес узла-отправителя.

Расширенный идентификатор, при его наличии, состоит из восемнадцати битов:

• старшие четыре бита — расширенный тип (подтип) кадра;
• остальные четырнадцать битов — зависят от базового типа и подтипа.

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

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

В групповых кадрах старший бит расширенного идентификатора всегда равен единице. Другими словами, все групповые кадры имеют подтип 8 или выше.

Кадры управления предназначены для функционирования всей сети CAN.

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

• CTRL_NODE — кадры присутствия узла;
• CTRL_SYNC — кадры синхронизации времени;
• CTRL_REQ и CTRL_RESP — кадры запросов и ответов Modbus.

Таблица 2. Формат расширенного идентификатора в кадрах CTRL

Кадры присутствия узла предназначены для оповещения остальных узлов о своем присутствии.

Кадры присутствия узла — это базовые кадры управления (без расширенного идентификатора). Кадры присутствия узла не содержат полезных данных, поэтому для их передачи требуется не более 55 битов.

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

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

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

Кадры синхронизации узла — это расширенные кадры управления с подтипом 2.

Кадр содержит время отправки предыдущего пакета. Время указывается в виде 64-битного числа в порядке little-endian. Число содержит количество наносекунд, прошедших с 01 января 1970 года 00:00:00.000.

Расширенный идентификатор содержит класс задатчика времени и номер последовательности.

Класс задатчика формируется из двух компонентов:

• старшие четыре бита — источник времени, используемый задатчиком;
• младшие четыре бита — тип устройства.

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

Номер последовательности увеличивается на 1 для каждого следующего кадра. При превышении максимального значения (63) номер сбрасывается в 0. Номер последовательности не стоит путать с номером группы.

Кадры подтверждения синхронизации времени — это расширенные пустые кадры управления с подтипом 4. Они передаются в течение 500 мс после получения кадра синхронизации времени (CTRL_SYNC) и содержат такие же класс задатчика времени и номер последовательности.

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

• кадр синхронизации CTRL_SYNC не был принят узлом;
• кадр подтверждения CTRL_SACK был отправлен узлом, но не дошел до мастера;
• узел не получил подтверждение отправленного им кадра CTRL_SACK и повторил передачу.

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

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

Кадры удержания линии — это расширенные кадры управления с подтипом 5 без данных.
При получении кадра удержания линии каждый участник сети сравнивает полученный код с собственным по принципу «меньше» — «важнее». Если полученный код оказывается более важным, узел должен на время освободить линию, то есть приостановить передачу выходных данных и дополнительной информации. Если полученный код совпадает с собственным кодом, то освобождать линию не требуется.

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

Таблица 5. Классификация задатчиков времени по источнику времени

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

Кадры запросов и ответов предназначены для управления узлами по протоколу MODBUS RTU.

Кадры запросов и ответов — это групповые расширенные кадры управления с подтипами 8 (запросы) и 9 (ответы).

Полезные данные группы содержат полный пакет MODBUS RTU, начиная с адреса устройства (который совпадает с адресом узла) и заканчивая контрольной суммой. Максимальный размер пакета MODBUS RTU — 256 байтов. Формат пакета в запросе полностью соответствует формату MODBUS RTU. Формат пакета в ответе отличается тем, что регистры не переворачиваются.

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

Запрос может быть отправлен любым узлом, но обычно их отправляет мастер CAN по инициативе пользователя (ПК).

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

Кадры данных разделены на следующие подтипы:

• DATA_FLOW — кадры потоковых данных;
• DATA_MESSAGE — кадры сообщений.

Таблица 6. Формат расширенного идентификатора в кадрах DATA

Кадры потоковых данных предназначены для передачи непрерывных чисел в формате IEEE 754 (float) с фиксированной частотой.

Кадры с потоковыми данными — это базовые кадры данных. Полезные данные содержат одно или два числа с плавающей запятой, в порядке little-endian. Частота выдачи чисел, единицы измерения и другие параметры соответствуют информации о канале.

Кадры сообщений предназначены для передачи данных, сгруппированных в виде сообщений.

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

Таблица 7. Формат сообщения DATA_MESSAGE

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

Кадры упакованных данных отличаются от кадров данных тем, что данные передаются в более экономном режиме.

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

Передача упакованных данных начинается с расширенного кадра PACK_START. В идентификаторе такого кадра указываются формат упакованных данных и количество последующих кадров, а в данных — секундная и наносекундная часть метки времени. Бит четности всегда 1 (то есть кадры PACK_START всегда нечетные).

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

Таблица 8. Формат расширенного идентификатора в кадрах PACK

Таблица 9. Формат базового идентификатора кадра упакованных данных

Формат сообщения определяет, что именно передается в самом сообщении. Более подробное описание форматов сообщений приведено в отдельной статье:
Формат ZDT для записи и передачи данных в ZETSENSOR.

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

Кадры дополнительной информации разделены на следующие подтипы:

• INFO_DIAG — кадры диагностических параметров;
• INFO_LINK — кадры информации о внешнем подключении;
• INFO_ZDT — кадры информации о канале.

Таблица 10. Формат расширенного идентификатора в кадрах INFO

Диагностический параметр — это пара из двух чисел: кода параметра (целое 14-битное) и его значения (float). Код параметра определяет все его характеристики, которые берутся из фиксированной таблицы диагностических параметров.

Каждый параметр передается отдельным кадром. Код параметра содержится в расширенном идентификаторе, а значение — в данных кадра.

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

Таблица 11. Перечень диагностических параметров

Кадры информации о внешнем подключении используются модулями, которые помимо CAN имеют интерфейс для связи с ПК или другими устройствами: Ethernet, USB, GSM и т.п. Рассылка кадров производится по изменению состояния подключения. Если состояние длительное время не меняется, то кадры рассылаются периодически, не реже одного кадра в десять секунд.

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

Таблица 12. Перечень внешних интерфейсов (link_interface)

Кадры содержат один байт с состоянием подключения указанного интерфейса.

Таблица 13. Перечень состояний подключения

В будущем могут быть задействованы другие байты данных кадра.

Кадры информации об узле — это групповые расширенные кадры дополнительной информации с подтипом 8.

Полезные данные группы содержат полный пакет в формате ZDT. Если узел имеет несколько видов информации (несколько пакетов ZDT), то каждый пакет передается отдельной группой.

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

Протокол может быть дополнен новыми базовыми типами и новыми подтипами в уже выделенных базовых типах.

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

Приведены примеры отправляемых пакетов для узла с адресом 3.

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

Для чтения содержимого вкладок используются кадры запросов и ответов MODBUS (CTRL_REQ и CTRL_RESP).

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