CAN FD

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

Как выглядит строка CAN-лога

Возьмем условную запись:

12.483251 ID 0x18A DLC 8 4A 01 7C 00 00 32 FF 10

Это учебный пример, а не запись конкретной машины. Формат файла у разных логгеров и программ отличается: могут добавляться номер канала, направление Rx/Tx, признаки расширенного кадра, CAN FD или ошибки. Поэтому сначала нужно найти описание колонок именно для используемого оборудования.

Из такой строки можно уверенно определить время наблюдения, ID, длину и сырые байты. Назвать 4A температурой, скоростью или состоянием реле без описания протокола нельзя.

Какие поля есть в кадре на шине

Программа обычно показывает не весь битовый кадр, а удобное представление его значимых полей. В Classical CAN кадр данных последовательно включает:

1. SOF – начало кадра, по которому узлы синхронизируются.
2. Поле арбитража – идентификатор и признак типа кадра.
3. Поле управления – в том числе IDE для различения формата идентификатора и DLC.
4. Поле данных – от 0 до 8 байт в Classical CAN.
5. CRC – контрольную последовательность для обнаружения ошибок передачи.
6. ACK – подтверждение корректного приема другими узлами.
7. EOF – конец кадра.

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

Идентификатор: 11 или 29 бит

Classical CAN поддерживает два формата кадра данных:

• базовый формат с 11-битным идентификатором, диапазон от 0x000 до 0x7FF;
• расширенный формат с 29-битным идентификатором, диапазон от 0x00000000 до 0x1FFFFFFF.

В логах 11-битный ID часто отображается тремя шестнадцатеричными цифрами, а 29-битный – числом длиной до восьми цифр. Но ширина записи сама по себе не является надежным признаком: программа может убрать ведущие нули или вынести тип кадра в отдельный флаг.

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

Например, J1939 использует 29-битные идентификаторы и раскладывает их поля по собственным правилам. Такой разбор относится уже не к базовому кадру CAN, а к протоколу верхнего уровня. Он отдельно описан в материале НСЭ о J1939.

DLC: код длины данных

DLC означает Data Length Code. В Classical CAN значения от 0 до 8 соответствуют количеству байтов в поле данных. Если в строке указано DLC 8, после него ожидаются восемь байтов.

Для CAN FD правило меняется после значения 8. Четырехбитное поле DLC по-прежнему содержит код от 0 до 15, но коды 9-15 обозначают фиксированные длины:

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

Байты данных: почему шестнадцатеричного ряда недостаточно

Каждая пара символов в примере представляет один байт: от 00 до FF. Восемь пар после DLC 8 – это восемь байтов. Но строка не сообщает, где внутри них находится конкретный сигнал.

Для перевода сырых данных в физическое значение нужно знать:

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

Эти сведения берут из документации протокола, спецификации производителя или DBC-файла. Без них байты можно сравнивать между режимами, искать изменения и повторяющиеся последовательности, но нельзя достоверно подписывать их как обороты, давление или температуру.

Временная метка: поле журнала, а не байт данных

Timestamp связывает принятый или переданный кадр с моментом наблюдения. Он может быть относительным, например в секундах от начала записи, или абсолютным – с датой и временем. Разрешение, точка отсчета и момент фиксации зависят от контроллера, логгера и формата файла.

В примере 12.483251 стоит рядом с кадром, но не передается в его поле данных. Стандарт и профиль временной привязки описывают, когда реализация захватывает timestamp при приеме или передаче. А уже средство записи решает, как представить эту метку в журнале.

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

Classical CAN и CAN FD: что видно в строке

У Classical CAN поле данных ограничено восемью байтами. CAN FD увеличивает его до 64 байт и может использовать другую скорость в фазе данных. Для различения форматов в кадре предусмотрен отдельный признак, а в журнале программа обычно показывает соответствующий флаг или тип записи.

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

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

Как разобрать незнакомую строку без ошибок

1. Найдите описание формата файла или заголовок таблицы.
2. Определите CAN-канал и направление записи, если они присутствуют.
3. Проверьте, стандартный или расширенный идентификатор используется.
4. Уточните, относится запись к Classical CAN или CAN FD.
5. Сопоставьте DLC с ожидаемым количеством байтов и пересчитайте пары hex.
6. Выясните единицы, точку отсчета и способ формирования временной метки.
7. Не декодируйте физические параметры без спецификации протокола или базы сигналов.
8. Сравните сообщение с соседними строками: частотой повторения, изменением байтов и моментом события.

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

Типичные ошибки при чтении CAN-лога

• Считать timestamp первым полем кадра. Обычно это метаданные регистратора рядом с кадром.
• Принимать CAN-ID за адрес блока. Назначение идентификатора определяет архитектура сети или протокол верхнего уровня.
• Читать DLC 15 как 15 байт CAN FD. Этот код соответствует 64 байтам.
• Назначать смысл отдельному байту по одному изменению. Совпадение может быть случайным, а сигнал может занимать несколько бит или байтов.
• Игнорировать порядок байтов и масштаб. Даже верно найденные биты еще нужно правильно преобразовать.
• Сравнивать время разных устройств без синхронизации. Смещение часов может изменить последовательность наблюдаемых событий.
• Путать строку лога с полным кадром на проводе. CRC, ACK и другие служебные поля часто не выводятся в обычной записи.

Как записывать CAN-данные для дальнейшего анализа

В каталоге НСЭ представлен CAN-логгер Саёратех. В действующей карточке указано, что устройство записывает Classical CAN и CAN FD с метками времени на съемную SD-карту, имеет два интерфейса CAN и интерфейс LIN. Состав сохраняемых полей и формат дальнейшего анализа нужно сверять с документацией и задачей проекта.

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

Технические сведения о форматах кадра сверены с материалами CAN in Automation о Classical CAN, CAN FD и временной привязке CiA 603.