Вопрос про CAN FD

Вопрос про CAN FD
По этой причине CAN FD еще не был внедрен в широком масштабе. Однако отсутствие более подходящих альтернатив в качестве протоколов передачи данных для бортовых устройств и необходимость увеличения пропускной способности шины делают внедрение этого стандарта неизбежным в ближайшие годы (1-3 года). Кроме того, другие перспективные протоколы уже потерпели поражение (FlexRay, Most).
С технической точки зрения, существует несколько проблем с этим протоколом. Наиболее важной с моей точки зрения является следующая. Производители автомобильного сетевого оборудования заинтересованы в увеличении пропускной способности шины. Однако на практике переход от классического CAN к CAN FD совершенно не изменяет скорость передачи сообщений, поскольку структура кадра остается практически неизменной. Фактически, количество данных в кадре просто увеличивается. Однако, поскольку сеть разделена на сообщения по функциональному признаку, увеличение количества данных, передаваемых в сообщении, не столь значительно, но увеличение пропускной способности шины для увеличения количества блоков управления на шине (плохое увеличение скорости) - вот что увеличивает пропускную способность шины. Переход на CAN FD, конечно, увеличит пропускную способность шины, но косвенно. Именно здесь пригодится сегментация сети и использование других интерфейсов (LIN, Ethernet) в зависимости от приложения.
CAN FD and Troubleshooting

Обработка видео...

CAN FD and Troubleshooting
Обновления CarBusAnalyzer. CANDB\OpenDBC, CAN-FD...

Обработка видео...

Обновления CarBusAnalyzer. CANDB\OpenDBC, CAN-FD
"ProByte Can-FD": KIA HYUNDAI (2022) airbag module with mcu Tricore Aurix crash reset by can-FD

Обработка видео...

"ProByte Can-FD": KIA HYUNDAI (2022) airbag module with mcu Tricore Aurix crash reset by can-FD

Практическая реализация интерфейса CAN FD в микроконтроллерах STMicroelectronics

Протокол CAN FD является эволюцией традиционного протокола CAN. Несколько изменений позволили увеличить фактическую скорость передачи данных CAN FD в несколько раз. При этом физическая реализация самой шины осталась неизменной. Это делает CAN FD наиболее привлекательным выбором для CAN-устройств. В данной статье кратко рассматриваются характеристики CAN FD, а также описывается практическая реализация CAN FD на базе микроконтроллера STM32.
История CAN началась в 1986 году, и с тех пор он стал одним из самых популярных протоколов; CAN широко используется в автомобилях, промышленном оборудовании, системах освещения и т.д. Основным преимуществом CAN является то, что более сложные элементы протокола (в частности, посредничество, формат кадра и физическая реализация) могут быть реализованы на уровне CAN-контроллера и CAN-приемопередатчика, что делает его простым в реализации. Это позволяет программистам сразу же начать передачу данных.
Несмотря на все преимущества CAN, в последнее время перегруженность полосы пропускания становится все более проблематичной для этого интерфейса. Объем информации постоянно растет, и фактически скорость передачи данных в 1 Мбит/с недостаточна для того, чтобы справиться с современными приложениями. Кроме того, были распространены 8- и 10-битные кодеры, но поскольку биты данных иногда достигают 24 бит и более, стало трудно уместить всю информацию в один кадр (8 байт), что делает неудобным переход на многокадровые сообщения.
Возможным решением этой проблемы является интерфейс CAN FD, который позволяет передавать больше данных в одном кадре, увеличивая скорость передачи [1]. Чтобы понять характеристики CAN FD, данная статья состоит из следующих разделов:

Краткий обзор физической реализации классической версии CAN

Архитектура шины CAN, согласно ISO 11898, предполагает использование витой пары с импедансом 120 Ом и двумя концевыми терминаторами 120 Ом
Краткий обзор физической реализации классической версии CAN
Специализированные приемопередатчики CAN отвечают за генерацию физических сигналов на шине и преобразование логических сигналов от контроллера CAN в дифференциальные сигналы. Используется двоичное кодирование, при котором низкое дифференциальное напряжение соответствует логической 1, а высокое дифференциальное напряжение - логическому нулю.
При передаче логического нуля на канале CANH генерируется напряжение около 3,5 В, а на канале CANL - около 1,5 В (дифференциальный сигнал 2 В). При передаче логической единицы на обоих каналах генерируется напряжение 2,5 В (дифференциальное напряжение близко к 0 В). В этом случае нижнее состояние - это низкое дифференциальное напряжение (логическая 1), а верхнее - высокое напряжение (логический 0). Это означает, что если один узел передает "1", а другой одновременно передает "0", то на шине будет "0". Эта важная особенность позволяет осуществлять неразрушающее посредничество.
Архитектура шины CAN в значительной степени способствовала широкому распространению CAN, поскольку она проста, удобна и недорога. Однако, к сожалению, стандарт ISO 11898 ограничивает скорость передачи данных CAN максимум 1 Мбит/с. Это связано с произвольным характером системы.
Согласно ISO 11898, CAN-коммуникация использует неразрушающий арбитраж с индивидуальными идентификаторами узлов. Перед началом передачи данных каждое устройство передает идентификатор и одновременно контролирует шину. Если обнаруживается несоответствие между переданным сигналом и состоянием шины, узел теряет арбитраж и прекращает передачу. Механизм арбитража показан на рисунке 2 [2]. Первоначально узлы C и B начинают посылать идентификаторы. Узел C посылает идентификаторы, начиная с последовательности 100, а узел B посылает идентификаторы, начиная с последовательности 101:
  • Первый шаг: узел C посылает "1", узел B посылает "1", в результате чего на шине наблюдается плохое состояние с низким дифференциальным напряжением.
  • Второй шаг. Узел C передает "0", узел B передает "0", в результате на шине наблюдается доминирующее состояние с высоким дифференциальным напряжением.
  • Третий шаг. Узел C передает "0", а узел B передает "1", в результате на шине наблюдается доминирующее состояние с высоким дифференциальным напряжением.
  • Четвертый шаг. Узел B обнаруживает несоответствие и проигрывает арбитраж. Узел C выигрывает арбитраж и возобновляет передачу.
Очевидно, что высокая степень синхронизации между узлами является необходимым условием для правильного функционирования механизма посредничества. Однако этому препятствуют различные задержки, такие как задержки в линиях передачи, задержки приемников, задержки передатчиков и другие эффекты искажения сигнала, например, дребезг. Витая пара, в частности, имеет задержку 5 нс/м. Поэтому проектировщик должен убедиться, что два наиболее удаленных узла могут достичь посредничества.
Вышеизложенное объясняет причину взаимосвязи между скоростью передачи и длиной шины. Чем выше скорость передачи, тем короче задержка сигнала. В таблице 1 приведены рекомендуемые значения длины шины, кванта времени и точки выборки битов при различных скоростях передачи [3]. Для максимальной скорости передачи 1 Мбит/с рекомендуемая длина линии составляет всего 25 м.

Рекомендуемые значения длины CAN-шины при различных скоростях передачи

Рекомендуемые значения длины CAN-шины при различных скоростях передачи
FDCAN in STM32 || Normal Mode || Message RAM Configuration

Обработка видео...

FDCAN in STM32 || Normal Mode || Message RAM Configuration
FDCAN Normal Operating Mode

Обработка видео...

FDCAN Normal Operating Mode
FDCAN in STM32 || LoopBack Mode

Обработка видео...

FDCAN in STM32 || LoopBack Mode
Приведенные значения были рассчитаны исходя из наихудших возможных условий. Однако в практическом оборудовании длина канала может быть увеличена за счет нормального кондиционирования канала, хорошего выбора передатчика и минимизации задержек.
С одной стороны, программисты не могут увеличить частоту передачи CAN "напрямую" из-за временных проблем при арбитраже. С другой стороны, как только арбитраж выполнен, ничто не мешает увеличить скорость передачи данных. Именно так и поступили создатели CAN FD.

Анализ формата фрейма в классической версии CAN

  • SOF – стартовый доминантный бит (Start of Frame), сообщающий о начале фрейма и позволяющий синхронизировать узлы после фазы ожидания;
  • ID – идентификатор узла (Identifier). Может иметь 11- или 29-битный размер. Устройство с меньшим ID выигрывает арбитраж. Соответственно, чем меньше ID, тем выше приоритет у устройства;
  • RTR – бит запроса сообщения (Remote Transmission Request). Если устройство передает данные, то бит RTR принимает рецессивное состояние. Если устройство запрашивает сообщение от другого узла – бит RTR принимает доминантное состояние;
  • IDE – бит-указатель на расширенный ID. Если IDE принимает доминантное состояние – это значит, что используется стандартный 11-битный идентификатор. Если IDE принимает рецессивное состояние, то принимающий контроллер должен быть готов к приему оставшейся части расширенного 29-битного идентификатора;
  • r0 – резервный бит;
  • DLC – 4-битное поле длины данных (Data Length Code), которое кодирует, сколько байтов данных будет передано в сообщении. В классическом CAN DLC может принимать значение в диапазоне 0…8.
  • DATA – поле данных. В классическом CAN фрейм может содержать 0…8 байтов данных;
  • CRC – 15-битный контрольный CRC-код для переданных данных;
  • CRC D – бит-ограничитель (Delimiter) для поля CRC;
  • ACK – бит подтверждения сообщения. В исходном фрейме передатчик использует рецессивное состояние этого бита. В свою очередь приемники при отсутствии ошибок должны установить в этом бите доминантное состояние. Другими словами, если на шине есть хотя бы один активный приемник, то в этом бите будет установлено доминантное состояние;
  • ACK D – бит-ограничитель (Delimiter) для ACK;
  • EOF – 7-битное поле окончания фрейма (End-of-Frame);
  • IFS – межфреймовый интервал (Interframe Space), необходимый для того чтобы приемник успел поместить сообщение в буфер.
Формат фрейма в классическом CAN (стандартный 11-битный ID)

Формат фрейма в классическом CAN (стандартный 11-битный ID)

В классической схеме CAN одновременно наблюдаются два недостатка:

Даже при 11-битных идентификаторах и максимальной длине данных. В лучшем случае на 64 бита полезных данных приходится 47 бит служебной информации, т.е. эффективность менее 58%,
Объем данных в кадре относительно небольшой - 8 байт. В ранних системах этого было достаточно, но сегодня объем данных значительно увеличился. Узлы должны передавать несколько кадров.
На первый взгляд кажется, что эти две проблемы можно решить напрямую, увеличив длину поля данных, но тогда шина будет постоянно перегружена, и устройства с более низким приоритетом могут оказаться недоступными. Кадр с 8 байтами данных (длина кадра 111 бит) обменивается со скоростью 250 кбит/с. Нетрудно подсчитать, что кадр с 8 байтами данных (длина кадра 111 бит) занимает шину в течение 0,4 мс при скорости 250 кбит/с. Если размер данных составляет 64 байта (длина кадра 559 бит или более), то шина будет занята за 5,6 мс. Это означает, что за это время ни одно устройство не сможет ничего передать. Очевидно, что для современных систем это неприемлемо.
Ограничения классического CAN также были учтены при разработке CAN FD.

Анализ формата фрейма в CAN FD

Для увеличения максимальной длины данных потребовалось скорректировать формат фрейма CAN FD.
Формат фрейма CAN FD представлен в таблице 3 [1]. Он имеет несколько важных отличий от формата фрейма классического CAN:
  • после передачи ID вместо бита RTR передается бит RRS, который всегда имеет доминантное состояние. Таким образом, в CAN FD поддерживаются только фреймы данных;
  • вместо зарезервированного бита R0, который всегда является доминантным в классическом CAN, передается рецессивный бит EDL (Extend Data Length), сообщающий о том, что это фрейм CAN FD;
  • бит BRS (Bit Rate Switching) сообщает приемнику о переключении частоты передачи при передаче данных (подробнее о переключении частот будет рассказано далее);
  • бит ESI (Error State Indicator) сообщает, что узел находится в режиме Error-active или Error-passive;
  • поле DLC осталось 4-битным и кодирует длину поля данных. В таблице 4 представлено соответствие между значениями DLC и длиной поля данных;
  • поле данных может иметь длину до 64 байт;
  • защита от потери данных кодируется 17/21-битным кодом CRC, который сопровождается полем счетчика бит-стаффинга (поле STC).
Формат фрейма в CAN FD (стандартный 11-битный ID)
Формат фрейма в CAN FD (стандартный 11-битный ID)
Кодирование длины данных в поле DLC в CAN FD
Большинство приведенных выше изменений кажутся достаточно простыми; стоит более подробно рассмотреть раздел CRC [5]. В классическом CAN используется 15-битный CRC-код, способный обнаружить до пяти битов ошибки. К сожалению, это возможно только при фиксированной длине поля данных, но с помощью bit stuffing длину поля данных можно варьировать.
Суть bit stuffing заключается в добавлении дополнительных неинформативных битов в исходный поток данных: в случае с CAN запрещено передавать шесть последовательных битов с одинаковой полярностью. Если обнаружено шесть последовательных битов с одинаковой полярностью, передатчик вставляет бит с противоположной полярностью после пятого бита. Таким образом, длина поля данных изменяется. Таким образом, в обычном CAN гарантируется обнаружение только одного "загрязненного" бита.
CAN FD решает эту проблему путем добавления счетчика суммирующих бит (плюс бит четности) и FSB (фиксированный бит) (Таблица 5) Бит CRC в CAN FD зависит от длины данных. Если поле данных меньше 16 байт, используется 17-битный CRC. Если длина данных превышает 16 байт, используется 21-битный CRC.
Формат поля STC и контрольной суммы CRC
Формат поля STC и контрольной суммы CRC
Таким образом, CAN FD позволяет передавать в 8 раз больше данных за фрейм, чем классический CAN. Доля полезных битов в фрейме CAN FD увеличивается, следовательно, эффективность возрастает.
Еще более важным изменением CAN FD стало увеличение частоты передачи данных.

Анализ скорости передачи данных CAN FD

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

CAN FD имеет следующие характеристики

При передаче служебной части кадра (начало и конец) может быть достигнута скорость до 1 Мбит/с или меньше (как в обычном CAN). При этом не возникает проблем с арбитражем, так как все остается неизменным,
При передаче полезной нагрузки (поля ESI, DLC, DATA, STC, CRC и CRC D) частота может быть увеличена по усмотрению пользователя, достигая 8 Мбит/с. Это может значительно увеличить фактическую скорость передачи. Типичная скорость CiA составляет 2/5/8 Мбит/с.
Давайте оценим повышение эффективности CAN FD при различных скоростях передачи и различной длине данных.

Сравнение производительности и средней скорости передачи данных CAN и CAN FD

Недостатком классического формата кадра CAN является большой объем служебной информации. Как показано в Таблице 6, короткий 11-битный идентификатор и 8 байт данных приводят к длине кадра 111 бит (без учета битов суммирования). Таким образом, на 64 полезных бита данных приходится 47 бит служебной информации, что составляет менее 58% эффективности для классического CAN (Таблица 7).
При использовании CAN FD эффективность гораздо выше, поскольку за кадр можно передать в восемь раз больше данных: на 574-битный кадр приходится 512 бит данных, т.е. 89% [5].
Следует отметить, что если кадр CAN FD содержит менее 8 байт данных, то его эффективность ниже, чем эффективность классического CAN. Это вполне очевидно из-за большего объема служебной информации, содержащейся в кадрах CAN FD.
STM32 CAN Communication || NORMAL Mode

Обработка видео...

STM32 CAN Communication || NORMAL Mode
FDCAN External Loop-back Mode

Обработка видео...

FDCAN External Loop-back Mode
Сравнение длин фреймов CAN и CAN FD
Сравнение длин фреймов CAN и CAN FD
Сравнение эффективности фреймов CAN и CAN FD
Эффективность кадров не полностью отражает возросшую производительность CAN FD. В то время как в обычном CAN скорость передачи постоянна, CAN FD позволяет передавать полезные данные в несколько раз быстрее, чем поле арбитража. Следовательно, средняя скорость передачи также увеличивается.
Для оценки средней скорости передачи можно использовать специальный калькулятор [5]. Результаты расчета для различных скоростей передачи данных приведены в таблице 8. Результаты показывают, что средняя скорость передачи данных CAN FD составляет 5,9 Мбит/с, что почти в шесть раз быстрее, чем у обычного CAN!
Средняя скорость передачи CAN FD

Семейства от STMicroelectronics с поддержкой CAN-FD

Компания STMicroelectronics выпускает различные семейства микроконтроллеров STM32 c поддержкой классического CAN. Поддержка CAN FD есть в следующих семействах [6]:
  • микроконтроллеры общего назначения STM32G0 с процессорным ядром ARM Cortex-M0+;
  • микроконтроллеры общего назначения STM32G4 с процессорным ядром ARM Cortex-M4;
  • производительные микроконтроллеры STM32H7 с процессорным ядром ARM Cortex-M7;
  • малопотребляющие микроконтроллеры STM32L5 с процессорным ядром ARM Cortex-M33.
Для практической реализации мы будем использовать микроконтроллер STM32L5.

Что такое CAN FD

Шина CAN-FD - это следующий этап эволюции классической шины CAN Шина CAN-FD - это следующий этап эволюции классической шины CAN.

Ключевые различия между CAN-FD и классической шиной CAN

  • CAN-FD работает одновременно на двух скоростях. Арбитражное поле или заголовок кадра передается на той же скорости, что и в классической версии (например, 500 кбит/с). Поле данных передается на скорости, кратной скорости заголовка (возможно, до 12 Мбит/с).
  • CAN-FD может передавать до 64 байт данных в пакете. Обычный CAN имеет максимальный предел в 8 байт.
  • Контроллеры CAN-FD могут принимать пакеты классического CAN, но контроллеры классического CAN не могут принимать пакеты в формате CAN-FD.
  • Для шины CAN-FD необходимо использовать специальную микросхему приемопередатчика с повышенной скоростью.

Почему на шине CAN-FD используется передача на двух скоростях

Скорость шины CAN ограничена, поскольку некоторые узлы на шине могут находиться в режиме передачи в определенное время суток. Это фаза согласования и ожидание подтверждения приема пакета. Поэтому каждый бит должен передаваться в течение времени, превышающего время, определяемое уровнем напряжения шины, достаточным для обмена данными между двумя узлами на шине.
Например, для шины CAN длиной 40 м максимальная скорость передачи данных составляет около 1 Мбит/с, чтобы обеспечить время передачи 1 бита. Однако это ограничение относится только к фазам "компромисс" и "ожидание подтверждения", упомянутым выше, и это ограничение скорости не распространяется на фазу передачи данных, когда имеется только один передатчик. Этот факт лег в основу нового стандарта CAN FD.
Компания BOSCH, разработчик стандарта CAN, решила увеличить в новом стандарте CAN-FD скорость передачи данных сегмента передачи байта между фазой компромисса и фазой ожидания подтверждения, включая поля ID и DLC.
Новый интерфейс CAN-FD

Обработка видео...

Новый интерфейс CAN-FD
Different between CAN and CAN-FD

Обработка видео...

Different between CAN and CAN-FD

Совместимость CANFD и классической шины CAN

Базовые форматы кадров CAN-FD и CAN  имеют различия. Контрольное поле в формате FD длиннее и несет больше информации.
CAN-FD кадр
CAN-FD кан шина
кадр CANFD, в контрольное поле добавлены биты:
  • FDF – признак того что кадр есть кадр CAN-FD
  • BRS – признак того что используется переключение битрейта
  • ESI – флаг того что счетчик ошибок узла полон
Бит IDE так же как и в классической реализации CAN указывает на то, что передаваемый пакет имеет расширенный 29-битный идентификатор.
Таким образом на шине CAN FD существуют следующие варианты передачи пакетов:
  1. В классическом CAN формате с количеством байт данных до 8.
  2. В формате CAN-FD с переключением скоростей и количеством байт данных до 64.
  3. В формате CAN-FD без переключения скоростей и количеством байт данных до 64 .
А так же эти же варианты но с 29-битным ID.
Из-за этого различия в основных форматах кадров CAN-FD и CAN, совместимость снизу вверх отсутствует. Поэтому модули CAN не могут принимать кадры CAN-FD. Однако модули CAN-FD могут принимать и передавать кадры в классическом формате.

Количество передаваемых данных

Шина CAN-FD может передавать до 64 байт данных в каждом кадре, что значительно увеличивает пропускную способность классического варианта CAN. Количество передаваемых байт также указывается в поле DLC, размер которого составляет 4 бита. Таким образом, соответствие между значением поля DLC и объемом передаваемых данных следующее:
DLC =0,  количество байт = 0;
DLC =1,  количество байт = 1;
DLC =2,  количество байт = 2;
DLC =3,  количество байт = 3;
DLC =4,  количество байт = 4;
DLC =5,  количество байт = 5;
DLC =6,  количество байт = 6;
DLC =7,  количество байт = 7;
DLC =8,  количество байт = 8;
DLC =9,  количество байт = 12;
DLC =10,  количество байт = 16;
DLC =11,  количество байт = 20;
DLC =12,  количество байт = 24;
DLC =13,  количество байт = 32;
DLC =14,  количество байт = 48;
DLC =15,  количество байт = 64;
Пакеты CAN-FD окне анализатора CarBusAnalyzer :
CAN-FD
CAN FD Explained - A Simple Intro (2020)

Обработка видео...

CAN FD Explained - A Simple Intro (2020)
Technical Comparison CANbus, CAN FD & Ethernet

Обработка видео...

Technical Comparison CANbus, CAN FD & Ethernet
CAN FD - поддержка программой Cantracer FD

Обработка видео...

CAN FD - поддержка программой Cantracer FD

Сигнал на шине CAN-FD на экране осциллографа

На экране осциллографа кадр CANFD выглядит следующим образом. Как видно передача данных идет на скорости кратно большей чем передача служебной информации.
CAN-FD
KIA Sorento 2021 CANFD

Обработка видео...

KIA Sorento 2021 CAN FD

Где применяется CAN-FD

По состоянию на декабрь 2020 года шина CANFD применяется  на автомобилях премиум класса производства: группы VAG, GM, Ford, BMW, KIA\HYUNDAI. При этом CAN-FD используется на критичных к скорости обмена участках сети CAN.
Например на автомобилях KIA Sorento MQ4, KIA Carival KA4 2021,Hyundai Tucson NX4 2021 года выпуска по шине CANFD происходит взаимодействие компонентов ADAS (радары, камеры), а так же по этой шине получает необходимые данные – панель приборов.
CAN-FD
На автомобилях Mercedes Benz с мультидоменной архитектурой сети так же применяется шина CAN-FD наряду с классической шиной CAN2.0
CAN-FD

Сегменты сети автомобилей Mercedes-Benz S-класс BR223 где применяется шина CAN-FD

CAN-FD

Чем отличается CAN FD от стандартного протокола CAN

CAN FD (Controller Area Network with Flexible Data Rate) - это протокол передачи данных, который развивался вместе с современной электроникой, позволяя инженерам-конструкторам повысить надежность связи в промышленных системах управления и автоматизации. Он позволяет инженерам-разработчикам повысить надежность связи в промышленных системах управления и автоматизации.
В конце 1980-х годов классический протокол CAN был создан для улучшения функциональности систем автомобильной электроники. В основном, все, что было связано с движением двигателей и механизмов, использовало систему CAN. Однако со временем резко возрос спрос на функции безопасности, такие как усовершенствованные электронные блоки управления (ECU) и передовые системы помощи водителю (ADAS).
Чтобы удовлетворить этот растущий спрос, необходим переход от традиционной системы CAN к новому протоколу, способному выдержать неизбежное увеличение объема обмена данными.
В то же время увеличилась скорость отправки и получения данных, поэтому CAN FD стал отраслевым стандартом. Так какие же изменения были внесены, чтобы помочь производителям и конструкторам поддерживать надежную передачу данных?
Tucson NX4. Новые фишки вариантного кодирования и контрольные суммы CAN-FD.

Обработка видео...

Tucson NX4. Новые фишки вариантного кодирования и контрольные суммы CAN-FD.
Программируем новые KIA 2022 через OBD2 при помощи CAN-Hacker CH-OBD-FD

Обработка видео...

Программируем новые KIA 2022 через OBD2 при помощи CAN-Hacker CH-OBD-FD
CAN-FD. Продолжаем разговор на примере SorentoMQ4. Bomber-FD, Coder-FD

Обработка видео...

CAN-FD. Продолжаем разговор на примере SorentoMQ4. Bomber-FD, Coder-FD

Длина кабеля

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

Пропускная способность.

В классических сетях CAN на один узел может быть передано только 8 байт данных, что было достаточно в 1980-х годах. Однако современные электронные блоки управления (ЭБУ) добавляют потоки данных таким образом, что логика не может быть быстро расшифрована через 8-битное соединение: при использовании протокола CAN FD на один кадр может приходиться 64 байта данных, что в восемь раз больше, чем может обработать классический CAN, или больше данных может быть сохранено.

Скорость передачи данных

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

Надежность.

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

Решение для микросхем CAN FD

Поскольку CAN FD все больше привлекает внимание промышленности, не ограничиваясь системами управления и автоматизации, недавно начали появляться решения на микросхемах, включающие функциональность CAN FD. Например, компания Microchip недавно представила PIC18Q84, первый 8-разрядный микроконтроллер семейства для сетей CAN FD. Микроконтроллеры Microchip нацелены на повышение безопасности передачи данных в сложных проектах.
CAN Bus Explained - A Simple Intro [v2.0 | 2021] 🌟

Обработка видео...

CAN Bus Explained - A Simple Intro [v2.0 | 2021] 🌟
Обновления CarBusAnalyzer. CANDB\OpenDBC, CAN-FD...

Обработка видео...

Обновления CarBusAnalyzer. CANDB\OpenDBC, CAN-FD
Этот микроконтроллер имеет Core-Independent Peripherals (CIP), которые позволяют системе отправлять и получать данные по шине CAN FD. Этот комбинированный пакет может выполнять задачи без использования центрального процессора системы. Microchip утверждает, что новое устройство обеспечивает практически нулевую задержку, уменьшая задержку интерфейса автомобиля и датчиков.
Традиционно при построении традиционных сетей CAN инженерам приходилось избегать критических задержек сообщений при сохранении достаточной длины кабеля; CAN FD обеспечивает большую гибкость при проектировании электромобилей, ЭБУ, роботизированных устройств, систем безопасного вождения и т.д. CAN FD соответствует кривой спроса в современных загруженных сетях передачи данных, однако в ближайшем будущем может потребоваться обновление протокола CAN в связи с увеличением объема передачи данных.

Launch CAN-FD (CAN Fast Data)

Launch CAN-FD (CAN Fast Data)
Шина CAN-FD (CAN Fast Data) является развитием обычной шины CAN, которая, как следует из названия, обеспечивает более высокую скорость передачи данных и больший объем передаваемых данных; основное отличие CAN-FD от обычной шины CAN заключается в том, что CAN-FD работает на двух скоростях до 12 Мбит/сек, в отличие от обычной CAN (максимум 8 байт);
в отличие от CAN-FD, которая может передавать до 64 байт данных в одном пакете, т.е. CAN-FD может принимать пакеты CAN, тогда как обычные CAN-адаптеры не могут принимать пакеты формата CAN-FD. Адаптеры CAN-FD могут принимать пакеты CAN, тогда как обычные адаптеры CAN не могут принимать пакеты формата CAN-FD.
Для шины CAN-FD требуется специальная микросхема приемопередатчика с более высокой скоростью.
Компания Launch разработала специальный адаптер CAN FD (ERP 301190732), который работает с одноименной шиной CAN FD. Этот адаптер предназначен для работы со всеми сканерами серии LAUNCH PRO/PAD, оснащенными адаптерами VCI типа DBScar II/IV/V. Для сканеров последнего поколения: PRO5/PAD V/V II с универсальным VCI типа Smartbox 3.0/SmartLink C, адаптер CAN FD не требуется, так как его поддержка уже включена в данный диагностический прибор.
До сих пор шина CAN FD использовалась исключительно в очень важных областях сети CAN в автомобилях высокого класса, таких как VAG, GM, Ford, BMW и KIA/Hyundai. Например, в автомобиле KIA Sorento 2021 года выпуска связь по шине CAN FD осуществляется между компонентами ADAS (радар, камера) и приборной панелью; адаптер CAN FD Launch был протестирован на автомобилях Chevrolet (все системы).

Шина CAN FD

Изобретенная компанией Bosch в конце 1980-х годов для удовлетворения растущего спроса на интеллектуальные легковые автомобили в немецкой автомобильной промышленности, технология CAN сегодня прочно вошла во встроенные системы управления реального времени для автомобильного и рельсового транспорта, станков с ЧПУ, лифтов, медицинского оборудования, аэрокосмических систем и т. д.
Однако в начале 2010-х годов ограничение пропускной способности шины CAN, соответствующее стандарту ISO 11898, и 8 байт данных на кадр шины CAN во многих случаях стали серьезными ограничениями из-за растущего объема данных, передаваемых между узлами сети, и увеличения количества узлов в сети CAN.
Кроме того, алгоритмы управления стали намного сложнее из-за увеличения производительности микроконтроллеров и встроенных компьютеров. Для реализации алгоритмов необходимо повысить точность датчиков, а такие датчики сегодня легко доступны. Поэтому если в 1990-х годах измеряемые параметры и уставки, рассчитываемые алгоритмами управления, содержали один или два байта, то в 2010-х годах нормой стали измеряемые значения и параметры управления в 14, 16 и 24 бита. Однако более точные данные уже не умещаются в одном кадре, что приводит к необходимости увеличения количества кадров, передающих сегментированные данные. Все это увеличивает сложность проектирования сети и снижает производительность, присущую интегрированной пропускной способности и средствам передачи.
Для решения этих проблем компания Bosch предложила мировому сообществу CAN новый вариант шины CAN - CAN FD (CAN с гибкой скоростью передачи данных), который расширяет стандарт CAN и позволяет масштабировать улучшения там, где предыдущие варианты CAN были проблематичны В 2016 году CAN FD стал международным стандартом ISO 11898-1:http://www.can-cia.org/fileadmin/resources/documents/brochures/can_fd.pdf.に採用されました。.
С введением CAN-FD можно реализовать скорость шины CAN до 5 Мбит/с в линейной топологии сети и 2 Мбит/с в топологии "звезда". Это достигается за счет увеличения скорости передачи только сегмента данных и увеличения длины поля данных до 64 байт (в обычном CAN максимальная длина байта составляет 8 байт). При этом скорость передачи остальных кадров CAN (арбитраж, служебные биты, CRC) не превышает 1 Мбит/с.
Классический вариант шины CAN широко используется в России. Однако на сегодняшний день в России нет отечественных устройств с высокоскоростной шиной CAN FD на базе отечественных компонентов.
Для того чтобы удержать российских разработчиков, создающих системы жесткого реального времени с передовыми компонентами для стандарта CAN-FD, компания "Марафон" запустила "Программно-аппаратную платформу для производства систем диагностики и управления мобильной морской техники".
Запуск привода стеклоподъемника по шине LIN. Control a window lift via LIN bus and CAN bus

Обработка видео...

Запуск привода стеклоподъемника по шине LIN. Control a window lift via LIN bus and CAN bus
Mercedes W205. Запускаем Audio20 по CAN. Working with the MB W205 Audio20 media centre by the CANbus

Обработка видео...

Mercedes W205. Запускаем Audio20 по CAN. Working with the MB W205 Audio20 media centre by the CANbus
CAN Bus Properties and Troubleshooting

Обработка видео...

CAN Bus Properties and Troubleshooting
Learn How The CAN Bus Works (Controller Area Network) | Embedded Systems Explained

Обработка видео...

Learn How The CAN Bus Works (Controller Area Network) | Embedded Systems Explained
Вопросы, комментарии, прошу оставить в комментариях
Поиск информации по сайту мониторинга транспорта TREKBERRY
© TREKBERRY 2017-2024, Дмитрий В.М. Все права защищены.
Копирование материала без ссылки на источник запрещено. Информация размещенная на сайте не является публичной офертой. Часть текстов написано нейросетью, ChatGPT может содержать не точности.