CAN шина. Часть 1: что, где, когда и зачем?

Здравствуйте, уважаемые посетители канала!

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

Итак, сегодня поговорим про то, что это вообще такое, зачем это создали.

Введение

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

Просто взгляните на этот весьма скромный пример, как выглядит общение между устройствами без (without) этой шины, и с ней (with). С первого взгляда - ничего особенного, но если представить, сколько в принципе в автомобиле всевозможных блоков и устройств, становится понятно, что количество проводки требовалось бы намного больше, а вместе с этим и ниже надёжность, сложнее ремонт и т.д.

Когда-то в автомобилях не было большого количества устройств и они взаимодействовали между собой, с автомобилем и водителем по вполне простой схеме - по отдельным проводам, но совершенствование автомобилей приводило к появлению электроники, а потом и к появлению всё более новых устройств и множества блоков управления, датчиков и исполнительных механизмов (тоже электронных). Всё это требует общения между собой и основным ЭБУ, а также сбор информации с датчиков (которых тоже становилось больше). Часто несколько разных устройств требовали показания по сути одного и того же датчика (например, ДТОЖ - Датчик Температуры Охлаждающей Жидкости). Сначала в таких датчиках по сути стояло по два элемента в одном корпусе, датчики также дублировались, итого можно было снимать показания температуры для 4-х устройств, имея всего два датчика, но даже такой подход требовал наличия дополнительной проводки. И так не только с датчиками. Проводка часто дублировалась. К тому же, дополнительные устройства\блоки управления должны были взаимодействовать между собой, а также с центральным ЭБУ автомобиля, и для этого тоже требовалась проводка. В конце концов, проводов становилось столько, что обслуживать такое было (мягко говоря) проблематично. Диагностировать тоже. Да и медь тяжёлая, одной только проводки по килограммам было достаточное количество. Потому инженеры задумались, а как бы сделать так, чтобы те же датчики опрашивались только одним центральным ЭБУ, а он в свою очередь отправлял остальным блокам эту информацию. Это бы избавило от дублирования датчиков, от лишней проводки, облегчило бы обслуживание\диагностику, к тому же это бы позволило настраивать все эти устройства без необходимости демонтажа с автомобиля. И решение было разработано в 1983 году компанией Bosch. Вернее, тогда это были лишь идеи, прототипы (да-да, озвученные выше проблемы уже были актуальны в 80-е годы). В 1986 году Bosch уже представила первую версию протокола CAN шины. Через год стали появляться уже и первые экспериментальные контроллеры CAN. Протокол совершенствовался, и в 1991 году была выпущена окончательная версия CAN 2.0, который и пошёл в массы. Кстати, первый автомобиль с протоколом CAN - это Mercedes-Benz W140, был он выпущен в том же 1991 году. Причём, несмотря на то, что хоть Bosch и выпустила\представила свой окончательный вариант CAN 2.0, этот стандарт не был стандартизирован (извините за тавтологию) в ISO, в связи с чем W140 был по сути "экспериментом", хоть и вполне успешным. ISO стандартизировала CAN 2.0 только в 1993 году, выпустив стандарт ISO 11898 (он есть даже в нашем ГОСТе, можете ознакомиться).

CAN 2.0 (ISO 11898)

Давайте коротко пройдёмся по этому стандарту (это важно для дальнейшего понимания). Стандарт определяет спецификации для сети контроллеров (CAN) в дорожных транспортных средствах. Он охватывает канальный уровень (Data Link Layer, DLL) и физический уровень (Physical Layer) модели OSI, обеспечивая надежную и эффективную передачу данных между электронными блоками управления (ECU) в автомобиле. Модель OSI (Open Systems Interconnection) - это эталонная модель, которая разработана для описания функций телекоммуникационных или вычислительных систем, необходимых для сетевого взаимодействия. Она разделяет процесс сетевого взаимодействия на семь взаимосвязанных уровней. Каждый уровень выполняет специфические функции и взаимодействует с уровнями непосредственно выше и ниже. Все уровни мы разбирать не будем, нас интересуют только два - Физический и Канальный.

Основные уровни модели OSI, реализуемые в CAN:

1. Физический уровень (Physical Layer)

Этот уровень отвечает за передачу сырых битов данных через физическую среду (кабели). В контексте CAN он определяет:

• Типы сигналов (доминантные и рецессивные состояния).
• Уровни напряжения для передачи данных.
• Электрические параметры, такие как волновое сопротивление (обычно 120 Ом).
• Среду передачи - обычно витую пару проводов.

💡 Пример: Если сигнал на обоих проводах одинаковый - это "рецессивный" бит (состояние). Если напряжение между ними разное - это "доминантный" бит (состояние).

Давайте рассмотрим физический уровень в CAN подробнее. Начнём с типов сигналов.

Доминантное состояние:

• Передача низкого уровня напряжения.
• Означает передачу логического 0.
• Обеспечивает возможность управления шиной.

Рецессивное состояние:

• Передача высокого уровня напряжения или отсутствие сигнала.
• Означает логическую 1.
• Используется, когда никто не передает данные, или для разрешения приоритетов.

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

Далее рассмотрим среду передачи. CAN шина обычно использует витую пару проводов для передачи данных:

• CAN_H (High): Передает доминантный высокий сигнал.
• CAN_L (Low): Передает доминантный низкий сигнал.

В нормальном состоянии, без передачи данных:

• CAN_H ≈ CAN_L (рецессивное состояние).
• Во время передачи данных: CAN_H поднимается до более высокого напряжения, чем CAN_L.

И наконец, пройдёмся по электрическим параметрам.

Напряжения на шине:

• Доминантное состояние:
• CAN_H ≈ 3.5 В.
• CAN_L ≈ 1.5 В.
• Рецессивное состояние:
• CAN_H ≈ CAN_L ≈ 2.5 В.

Согласование сопротивления:

• Для уменьшения отражений сигнала и обеспечения корректной передачи на концах шины устанавливаются терминальные резисторы (обычно 120 Ом).

Скорости передачи:

• Стандартный CAN: до 1 Мбит/с.

2. Канальный уровень (Data Link Layer)

Этот уровень управляет передачей данных по шине и включает два подуровня:

a) Medium Access Control (MAC):

MAC управляет доступом устройств к общей шине передачи данных, используя метод Carrier Sense Multiple Access with Collision Resolution (CSMA/CR).

Основные функции MAC:

1. Арбитраж при передаче данных:
• Устройства с более приоритетным сообщением (меньший идентификатор) получают право на передачу.
• Приоритизация обеспечивается благодаря доминантным и рецессивным битам.
• Механизм позволяет избежать коллизий на уровне данных.
2. Рамка сообщения (CAN Frame):
   MAC формирует кадры сообщений, которые включают:
• Идентификатор сообщения (Identifier): Определяет приоритет сообщения.
• Биты управления (Control Bits): Указывают длину данных, тип кадра и другие параметры.
• Поле данных (Data Field): Полезная нагрузка (до 8 байт для стандартного CAN, до 64 байт для CAN FD).
• Контрольная сумма (CRC): Для проверки ошибок.
3. Контроль ошибок на шине:
• CAN автоматически обнаруживает ошибки (например, при изменении бита из-за помех).
• Устройства участвуют в ACK-сигнале: каждое устройство подтверждает правильное получение сообщения. Если подтверждение отсутствует, передача повторяется.
4. Повторная передача:
   Если устройство обнаруживает ошибку или не получает подтверждение, оно повторяет отправку сообщения.

b) Подуровень управления логической связью (Logical Link Control, LLC)

LLC обеспечивает функции более высокого уровня, такие как фильтрация сообщений и проверка целостности данных.

Основные функции LLC:

1. Адресация и фильтрация сообщений:
• Устройства получают все сообщения на шине, но обрабатывают только те, которые соответствуют их настройкам фильтрации.
• Фильтры настраиваются для обработки сообщений с определенными идентификаторами.
2. Обнаружение ошибок:
• Используется метод циклического избыточного контроля (CRC) для проверки целостности данных.
• Проверяются ошибки синхронизации и формата (например, структура кадра).
3. Синхронизация и управление потоками:
• CAN использует метод битового наполнения (Bit Stuffing) для предотвращения синхронизационных ошибок:
• После 5 одинаковых битов подряд автоматически вставляется противоположный бит.
4. Управление подтверждениями (ACK):
• Устройство, успешно получившее сообщение, отправляет подтверждение в ACK-фазе.
• Если подтверждение отсутствует, сообщение считается недоставленным.

Ключевые компоненты канального уровня

1. Типы кадров (CAN Frame):
• Data Frame: Для передачи данных.
• Remote Frame: Для запроса данных у других устройств.
• Error Frame: Для уведомления об ошибке.
• Overload Frame: Для запроса времени на обработку сообщений.
2. Приоритет сообщений:
   Приоритет определяется идентификатором:
• Чем меньше идентификатор, тем выше приоритет.
• Устройства с более низким приоритетом автоматически отступают при передаче.
3. Обнаружение ошибок:
   В CAN предусмотрены 5 типов ошибок:
• Битовая ошибка (Bit Error): Устройство передает бит, но видит на шине другой.
• Ошибка заполнения (Stuff Error): Ошибка в битовом наполнении.
• Ошибка формата (Form Error): Неправильная структура кадра.
• Ошибка ACK (Acknowledgment Error): Отсутствие подтверждения от получателей.
• CRC-ошибка: Несоответствие контрольной суммы.
4. Режимы работы устройств:
   Устройства могут работать в режиме:
• Только передача (Transmit-Only): Устройство только отправляет данные.
• Только прием (Receive-Only): Устройство только получает данные.
• Смешанный режим (Mixed): Устройство может и передавать, и принимать данные.

💡 Пример работы канального уровня

1. ECU двигателя хочет отправить данные в ECU коробки передач.
2. Через MAC определяет, что шина свободна.
3. Начинает передачу данных, формируя кадр с идентификатором сообщения и полезной нагрузкой.
4. Остальные устройства на шине получают это сообщение, но обрабатывает его только ECU коробки передач (благодаря фильтрации в LLC).
5. После успешного приема ECU коробки передач отправляет подтверждение (ACK).

Если в процессе произошла ошибка (например, битовая ошибка из-за помех), сообщение будет автоматически переслано.

Сложно? Можете прочитать отдельно про каждый уровень OSI, которые здесь рассмотрены, я лишь пояснил, какие из них реализованы стандарте CAN, и как именно. В следующей статье рассмотрим, что такое OBD-II и при чём тут CAN.