Controller Area Network (CAN) Bus

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

Введение

Controller Area Network (CAN) — надёжный и универсальный протокол связи, позволяющий передавать данные между платой Arduino и другими устройствами в сетевой среде без хост-компьютера. Изначально разработанный компанией Bosch для автомобильных приложений, CAN Bus обладает преимуществами в сценариях, требующих устойчивой, помехозащищённой передачи данных с проверкой ошибок.

Связь по CAN обеспечивается различными библиотеками CAN и зависит от аппаратного обеспечения, используемого в проекте. В данной статье основное внимание уделяется библиотеке Arduino_CAN и её методам, а также ссылкам на различное аппаратное обеспечение и соответствующие библиотеки.

Класс CAN

С помощью класса CAN можно отправлять и принимать данные по шине Controller Area Network (CAN), обеспечивая обмен данными между платой Arduino и другими устройствами в сетевой среде.

• Класс CAN предоставляет методы для управления CAN-коммуникацией, как правило используемые с конкретными платами Arduino, поддерживающими CAN, например Arduino UNO R4, или с дополнительными шилдами, такими как MKR CAN Shield.

Класс CAN имеет несколько ключевых методов:

• begin(CanBitRate rate) — Инициализирует CAN Bus с заданной скоростью передачи (например, CanBitRate::BR_250k для 250 кбит/с).

• available() — Проверяет наличие входящих CAN-сообщений, доступных для чтения.

• read() — Читает CAN-сообщение из шины и возвращает его в виде объекта CanMsg.

• write(const CanMsg& msg) — Записывает CAN-сообщение на шину. Сообщение инкапсулировано в объект CanMsg, который включает CAN ID, длину данных и полезную нагрузку.

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

Пины CAN на плате Arduino

Важно

В зависимости от используемой платы Arduino вам может потребоваться трансивер/приёмник для корректного считывания дифференциального сигнала. Обратитесь к странице продукта или таблице характеристик (cheat sheet) используемой платы для получения дополнительной информации.

Технические характеристики

История CAN

Шина CAN, или Controller Area Network, была разработана немецкой компанией Bosch в 1980-х годах. Основная цель — упростить обмен данными внутри транспортных средств, позволив различным микроконтроллерам и устройствам взаимодействовать без центрального хост-компьютера. Это нововведение значительно повысило эффективность и надёжность автомобильных систем, обеспечив обмен данными в реальном времени и скоординированное управление различными компонентами автомобиля. Устойчивость CAN к помехам сделала его особенно пригодным для эксплуатации в жёстких условиях, характерных для автомобилей.

Версии стандарта CAN

Название	Год	Скорость
CAN 1.0	1986	До 125 килобит в секунду
CAN 2.0	1991	До 1 Мегабита в секунду
CAN FD	2011	До 1 Мбит/с (фаза арбитража), до 8 Мбит/с (фаза данных)
CAN XL (Extra Large)	В разработке (по состоянию на 19.08.2024)	Более высокие скорости (в разработке)

Хронология стандартов

1986: CAN 1.0

Первая версия протокола CAN была выпущена в 1986 году и поддерживала скорость передачи до 125 килобит в секунду. Изначально она применялась преимущественно для диагностической связи внутри транспортных средств.

1991: CAN 2.0

Был выпущен влиятельный стандарт CAN 2.0, ставший значительным шагом вперёд. Эта версия поддерживала скорость передачи до 1 мегабита в секунду и ввела два формата фреймов: стандартный 11-битный идентификатор и расширенный 29-битный идентификатор. CAN 2.0 получил широкое распространение не только в автомобильных приложениях, но и в промышленных и других встраиваемых системах. При использовании Arduino именно эта версия поддерживается библиотекой Arduino_CAN по состоянию на 15.08.2024.

2003: Стандартизация ISO

Технология CAN была стандартизирована Международной организацией по стандартизации (ISO) как ISO 11898-1. Это помогло формализовать протокол и обеспечить совместимость и надёжность различных реализаций.

2011: CAN FD (Flexible Data Rate)

CAN FD был введён для удовлетворения современных требований к более высоким скоростям передачи данных и увеличенным полезным нагрузкам. CAN FD поддерживает скорость до 1 мегабита в секунду в фазе арбитража и до 8 мегабит в секунду в фазе данных. Кроме того, размер полезной нагрузки увеличился до 64 байт по сравнению с ограничением в 8 байт в CAN 2.0.

2015: ISO 11898-1:2015

Последняя редакция стандарта ISO включила CAN FD, сделав его неотъемлемой частью международного стандарта для CAN.

В разработке: CAN XL (Extra Large)

В настоящее время CAN XL находится в разработке и призван ещё больше расширить возможности протокола CAN, предлагая ещё более высокие скорости передачи и бо́льшие полезные нагрузки. Это непрекращающееся развитие обусловлено необходимостью конкурировать с Ethernet и другими высокоскоростными протоколами связи в автомобильных и промышленных приложениях.

Принцип работы CAN

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

Общая шина и отсутствие центрального мастер-узла

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

Дифференциальный сигнал

CAN использует схему дифференциального сигнала: биты данных представлены разностью напряжений между двумя проводами — CAN_H (CAN High) и CAN_L (CAN Low). Дифференциальный характер CAN делает его высокоустойчивым к электрическим помехам, обеспечивая надёжную связь на большие расстояния и в условиях помех, характерных для автомобильных и промышленных применений.

Практический пример: CAN в автомобильных системах

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

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

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

Соображения по поводу заземляющего провода

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

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

• Безопасность и надёжность: В автомобиле кузов нередко служит общей землёй, обеспечивая работу всех устройств при совместимых уровнях напряжения, что снижает вероятность ошибок связи и повышает общую стабильность системы.

Пример коллизии и метод арбитража шины CAN

CAN Bus использует неразрушающий побитовый метод арбитража для обработки коллизий. Когда два узла пытаются одновременно отправить сообщения, побеждает узел с наивысшим приоритетом (наименьшим CAN ID), а другой узел отступает и повторяет попытку.

Пример:

• Предположим, что узел 1 отправляет сообщение с ID 0x100, а узел 2 — с ID 0x101 одновременно. Поскольку 0x100 имеет более высокий приоритет (меньшее числовое значение), узел 1 продолжает передачу, тогда как узел 2 останавливается и повторяет попытку после завершения передачи узла 1.

Структура фрейма CAN

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

Формат фрейма

Стандартные и расширенные CAN ID

CAN-фреймы существуют в двух форматах: стандартном и расширенном. Основное различие между ними — длина поля идентификатора.

• Стандартный CAN ID: Использует 11-битный идентификатор, позволяя задать 2 048 уникальных идентификаторов сообщений.

• Расширенный CAN ID: Использует 29-битный идентификатор, обеспечивая значительно большее адресное пространство — 536 870 912 уникальных идентификаторов сообщений.

Типичный CAN-фрейм состоит из следующих полей:

1. Начало фрейма (SOF — Start of Frame): Маркирует начало фрейма доминантным битом, синхронизируя все узлы к началу сообщения.

2. Поле арбитража (Arbitration Field):

   • Идентификатор (Identifier): Уникальное значение, используемое для идентификации сообщения и определения его приоритета в процессе арбитража.

   • RTR (Remote Transmission Request): Различает фреймы данных и удалённые фреймы (запросы данных).

3. Поле управления (Control Field):

   • IDE (Identifier Extension): Указывает, является ли поле идентификатора стандартным (11 бит) или расширенным (29 бит).

   • r (Зарезервированный бит): Зарезервирован для будущего использования, должен всегда быть доминантным.

   • DLC (Data Length Code): Задаёт количество байт данных (от 0 до 8 байт).

4. Поле данных (Data Field): Содержит фактическую полезную нагрузку — от 0 до 8 байт.

5. Поле CRC:

   • CRC Sequence: Хранит значение циклического избыточного кода (CRC) для обнаружения ошибок.

   • CRC Delimiter (DEL): Одиночный рецессивный бит, разделяющий поле CRC и поле подтверждения.

6. Поле ACK:

   • ACK Slot: Сигнализирует об успешном получении сообщения установкой доминантного бита.

   • ACK Delimiter (DEL): Следует за битом подтверждения и является рецессивным.

7. Конец фрейма (EOF — End of Frame): Состоит из семи рецессивных битов, маркирующих окончание фрейма.

8. Межфреймовое пространство (ITM — Interframe Space): Период бездействия шины между последовательными фреймами данных, обеспечивающий простой шины перед следующим сообщением.

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

Синхронизация и временны́е характеристики

Синхронизация и временны́е характеристики — критически важные аспекты CAN-коммуникации. В отличие от синхронных последовательных протоколов, таких как SPI и I2C, CAN работает асинхронно, то есть не использует общий тактовый сигнал. Вместо этого для определения временны́х интервалов битов данных применяются заранее заданные скорости передачи.

Фазы временно́го интервала бита

Несмотря на асинхронную природу, CAN обеспечивает точную синхронизацию между узлами с помощью механизма bit timing (временно́й привязки бита), который состоит из следующих фаз:

• Сегмент синхронизации (Sync Segment): Используется для синхронизации узлов. Все узлы определяют начало сообщения по переходу от рецессивного бита к доминантному.

• Сегмент распространения (Propagation Segment): Учитывает физические задержки распространения сигнала в сети.

• Фазовый сегмент 1 (PS1 — Phase Segment 1): Помогает компенсировать ошибки фазовых фронтов.

• Фазовый сегмент 2 (PS2 — Phase Segment 2): Обеспечивает дополнительную компенсацию фазовых ошибок.

Временно́й интервал бита разбивается на временны́е кванты (TQ — Time Quanta) — наименьшие единицы времени в CAN-коммуникации. Общее количество TQ в периоде одного бита определяет временну́ю привязку бита, скорректированную для обеспечения высокой надёжности связи.

В коде скорость передачи задаётся следующим образом:

CAN.begin(CanBitRate::BR_250k);

Оконечные резисторы

Оконечные резисторы необходимы для правильной работы CAN Bus сети. Они предотвращают отражения сигнала, которые могут вызывать ошибки связи. Как правило, резистор сопротивлением 120 Ом подключается между CAN_H и CAN_L на каждом конце шины.

Подключение оконечных резисторов

Для добавления оконечных резисторов подключите резистор 120 Ом между линиями CAN_H и CAN_L на обоих концах CAN Bus. Это обеспечит правильное завершение электрических сигналов, предотвращая отражения и поддерживая целостность сигнала.

Примеры

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

• Arduino UNO R4 WiFi CAN Bus

• Отправка данных между двумя MKR CAN Shield