CAN (Control Area Network) —
последовательная
магистраль,
обеспечивающая
увязку в
сеть «интеллектуальных»
устройств
ввода/вывода,
датчиков и
исполнительных
устройств
некоторого
механизма
или даже
предприятия.
Характеризуется
протоколом,
обеспечивающим
возможность
нахождения
на
магистрали
нескольких
ведущих
устройств,
обеспечивающим
передачу
данных в
реальном
масштабе
времени и
коррекцию
ошибок,
высокой
омехоустойчивостью.
Система CAN
обеспечена
большим
количеством
микросхем,
обеспечивающих
работу
подключенных
к
магистрали
устройств,
разработку
которых
начинала
фирма BOSH для
использования
в
автомобилях,
и в
настоящее
время
широко
используемых
в
автоматизации
промышленности.
Цеколёвка
разема
приведена
на рисунке.
| Стандарт | ISO 11898 |
| Скорость передачи |
1 Мбит/с (максимум) |
| Расстояние передачи |
1000 м (максимум) |
| Характер сигнала, линия передачи |
дифференциальное напряжение, скрученная пара |
| Количество драйверов |
64 |
| Количество приемников |
64 |
| Схема соединения |
полудуплекс, многоточечная |
- Предназначен
для
организации
высоконадежных
недорогих
каналов
связи в
распределенных
системах
управления.
Интерфейс
широко
применяется
в
промышленности,
энергетике
и на
транспорте.
Позволяет
строить
как
дешевые
мультиплексные
каналы, так
и
высокоскоростные
сети. - Скорость
передачи
задается
программно
и может
быть до 1
Мбит/с.
Пользователь
выбирает
скорость,
исходя из
расстояний,
числа
абонентов
и емкости
линий
передачи.
| Расстояние, м |
25 | 50 | 100 | 250 | 500 | 1000 | 2500 | 5000 |
| Скорость, Кбит/с |
1000 | 800 | 500 | 250 | 125 | 50 | 20 | 10 |
- Максимальное
число
абонентов,
подключенных
к данному
интерфейсу
фактически
определяется
нагрузочной
способностью
примененных
приемопередатчиков.
Например,
при
использовании
трансивера
фирмы PHILIPS PCA82C250
она равна 110. - Протокол CAN
использует
оригинальную
систему
адресации
сообщений.
Каждое
сообщение
снабжается
идентификатором,
который
определяет
назначение
передаваемых
данных, но
не адрес
приемника.
Любой
приемник
может
реагировать
как на один
идентификатор,
так и на
несколько.
На один
идентификатор
могут
реагировать
несколько
приемников. - Протокол CAN
обладает
развитой
системой
обнаружения
и
сигнализации
ошибок. Для
этих целей
используется
поразрядный
контроль,
прямое
заполнение
битового
потока,
проверка
пакета
сообщения CRC-полиномом,
контроль
формы
пакета
сообщений,
подтверждение
правильного
приема
пакета
данных.
Хемминговый
интервал d=6.
Общая
вероятность
необнаруженной
ошибки 4.7×10-11. - Система
арбитража
протокола CAN
исключает
потерю
информации
и времени
при «столкновениях»
на шине. - Интерфейс
с
применением
протокола CAN
легко
адаптируется
к
физической
среде
передачи
информации.
Это может
быть
дифференциальный
сигнал,
оптоволокно,
просто
открытый
коллектор
и т.п.
Несложно
делается
гальваническая
развязка. - Элементная
база,
поддерживающая
CAN, широко
выпускается
в
индустриальном
исполнении.
CAN 2.0 А
1.
Введение
CAN (Controller Area Network) —
это
последовательный
протокол
связи с
эффективной
поддержкой
распределения
контроля в
реальном
времени и
очень
высоким
уровнем
безопасности.
Основное
назначение:
организация
передачи
информации
в сложных
условиях,
таких как
среды с
высоким
уровнем
различного
рода помех.
Этот
протокол
передачи
применяется
в
автомобильной
электронике,
машинных
устройствах
управления,
датчиках
при
передаче
информации
со
скоростями
до 1 Мбит/сек.
Протокол
CAN можно
разделить
на
следующие
уровни:
- объектный
уровень - канальный
уровень - физический
уровень
Объектный
и канальный
уровни
включают
весь сервис
и функции
передачи
данных
определяемых
ISO/OSI моделью.
Область
объектного
уровня
включает:
- Поиск
сообщений
для
передачи. - Фильтрация
сообщений,
полученных
от
канального
уровня - Обеспечение
связи
между
прикладным
уровнем и
аппаратными
средствами.
Объектный
уровень
можно
реализовывать
различными
способами.
Область
канального
уровня
главным
образом —
протокол
передачи, т.е.
управление
кадрами,
выполнение
арбитража,
проверка и
сигнализация
ошибок,
типизация
ошибок.
Внутри
канального
уровня
решается,
является ли
шина
свободной
для начала
новой
передачи.
Все что
находится
внутри
канального
уровня, не
имеет ни
какой
свободы к
модификации.
Область
физического
уровня —
фактическая
передача
бит между
различными
узлами.
Внутри
одной сети
физический
уровень
должен быть
одинаков
для всех
узлов.
Физический
уровень
можно
реализовать
различными
способами.
2.
Основные
характеристики
протокола
- каждое
сообщение
имеет
определенный
приоритет - существуют
гарантированные
времена
ожидания - гибкость
конфигурации - групповой
приём с
временной
синхронизацией - система
непротиворечивости
данных - multimaster
- обнаружение
и
сигнализация
ошибок - автоматическая
ретрансляция
разрушенных
сообщений - различие
между
временными
ошибками и
постоянными
отказами
узлов и
автономное
отключение
дефектных
узлов
Сообщения
Информация
по шине
посылается
в
фиксированном
формате
сообщений
различной,
но
фиксированной
длины. Когда
шина
свободна,
любой узел
может
начать
передачу
нового
сообщения.
Информационная
маршрутизация
В CAN
нет ни какой
информации
относительно
конфигурации
сети (например,
адреса узла).
Это имеет
несколько
важных
следствий:
Гибкость
системы:
Узел
может быть
добавлен в CAN —
сеть, без
каких либо
изменений в
программном
или
аппаратном
обеспечении,
какого — либо
узла в сети.
Маршрутизация
сообщений:
Содержание
сообщения
определяется
идентификатором.
Идентификатор
не
указывает
адреса
сообщения, а
описывает
значение
данных так,
чтобы все
узлы сети
были
способны
решить
фильтрацией
сообщений,
нужны им эти
данные или
нет.
Передача
группе:
Как
следует из
фильтрации
сообщений,
любое число
узлов может
одновременно
получать и
реагировать
на одно и
тоже
сообщение.
Непротиворечивость
данных:
Внутри
сети CAN
гарантировано,
что
сообщение
принято
всеми
узлами или
ни одним
узлом.
Скорость
передачи
информации
Скорость
передачи
информации
в CAN — сети
может быть
различной
для каждой
сети. Однако
в каждой
конкретной
сети
скорость
передачи
информации
фиксирована.
Приоритеты
Идентификатор
и RTR — бит
определяют
статический
приоритет
сообщения в
течение
доступа к
шине.
Удаленный
запрос
данных
Посылая
кадр
удаленного
запроса
данных, узел
может
потребовать
данные от
другого
узла. Кадр
данных и
кадр
удаленного
запроса
данных
должны
иметь
одинаковый
идентификатор.
Multimaster
Когда
шина
свободна,
любой узел
может
начать
передачу
сообщения.
Доступ к
шине
получает
узел,
передающий
кадр с
наивысшим
приоритетом.
Арбитраж
Когда
шина
свободна,
любой узел
может
начать
передачу
сообщения.
Если два или
больше узла
начинают
передавать
сообщения в
одно и тоже
время,
конфликт
при доступе
к шине будет
решен
поразрядным
арбитражем
используя
идентификатор
и RTR — бит.
Механизм
арбитража
гарантирует,
что ни время,
ни
информация
не будут
потеряны.
Если кадр
данных и
кадр
удаленного
запроса
данных
начинают
передаваться
в одно время,
то кадр
данных
имеет более
высокий
приоритет,
чем кадр
удаленного
запроса
данных. В
течение
арбитража
каждый
передатчик
сравнивает
уровень
переданного
бита с
уровнем,
считываемым
с шины. Если
эти уровни
одинаковы,
узел может
продолжать
посылать
данные
дальше. Если
был послан
уровень лог.
‘1’ (recessive), а с шины
считан
уровень лог.
‘0’ (dominant), то узел
теряет
право
дальнейшей
передачи
данных и
должен
прекратить
посылку
данных на
шину.
Безопасность
Чтобы
достичь
высокой
безопасности
передачи
данных,
приняты
мощные меры
нахождения
ошибок,
сигнализации
ошибок и
самотестирование
в каждом CAN —
узле.
Обнаружение
ошибок
Для
обнаружения
ошибок
приняты
следующие
меры:
- текущий
контроль (передатчики
сравнивают
уровни
битов,
которые
переданы, с
уровнями
на шине). - побитовое
заполнение - проверка
кадра
сообщения
Эффективность
обнаружения
ошибок
Механизмы
обнаружения
ошибок
имеют
следующие
возможности:
- обнаружение
всех
глобальных
ошибок - обнаружение
всех
локальных
ошибок
передатчиков - обнаружение
до 5
случайно
распределённых
ошибок в
сообщении - обнаружение
последовательной
группы
ошибок
длиной до 15 - обнаружение
любого
числа
нечетных
ошибок в
сообщении
Общая
остаточная
вероятность
ошибки для
необнаруженных,
разрушенных
сообщений,
меньше чем:
скорость
появления
ошибки * 4.7*10Е-11
Сигнализация
ошибки и
время
восстановления
Разрушенные
сообщения
помечаются
узлом,
обнаружившим
ошибку.
Такие
сообщения
прерываются
и будут
переданы
снова. Время
восстановления
от
обнаружения
ошибки до
начала
следующего
сообщения в
большинстве
случаев = 29 *
время
передачи
одного бита,
если не
имеется
никаких
дальнейших
ошибок.
Типизация
ошибок
Узлы
CAN способны
отличить
временные
ошибки от
постоянных
отказов.
Дефектные
узлы будут
отключены.
Соединения
Линия
связи по
протоколу CAN —
это шина, к
которой
может быть
подключён
ряд узлов.
Количество
узлов не
имеет
никакого
теоретического
предела.
Фактически
количество
узлов будет
ограничено
временами
задержек и/или
электрической
нагрузкой
на линии
шины. Способ,
которым
выполнена
шина, не
установлен
в данной
спецификации.
Например,
это может
быть
одиночный
провод (+земля),
два
дифференциальных
провода,
оптическое
стекловолокно.
Уровни
шины
Шина
может
принимать
одно из
дополняющих
друг друга
значений:
«dominant» и «recessive». В
случае
одновременной
подачи «dominant»
бита и «recessive»
бита,
возникающее
в
результате
значение
шины будет
«dominant».
(Прим.
переводчика:
далее
считается
что «recessive» = лог.
«1», а «dominant» = «0»).
Подтверждение
Все
приёмники
проверяют
непротиворечивость
принимаемого
сообщения и
подтверждают
непротиворечивое
сообщение.
Режим
«сна» /
пробуждения
Чтобы
уменьшить
потребляемую
мощность
системы,
узел CAN может
быть
переведен в
режим «сна».
Режим «сна»
заканчивается
при любом
действии на
шине или
внутреннем
состоянии
системы. При
пробуждении
запускается
внутренняя
синхронизация,
канальный
уровень
ждёт
стабилизации
генератора
системы, а
затем будет
ожидать
самосинхронизации
к действиям
на шине (синхронизация
к действиям
на шине
заканчивается
после
принятия
последовательности
11 битов с лог.
«1»). Для
пробуждения
узла из
режима
покоя может
использоваться
некоторое
сообщение
пробуждения
со
специальным
идентификатором.
3.
Передача
сообщений
При
передаче
информации
с помощью
протокола CAN
используется
четыре типа
кадров. Кадр
данных
содержит
данные,
передаваемые
передатчиком
приёмнику (ам).
Кадр
удаленного
запроса
данных
передается
на шину для
запроса
передачи
кадра
данных с тем
же самым
идентификатором.
Кадр ошибки
передаётся
при
обнаружении
ошибки на
шине. Кадр
перегрузки
используется
для
обеспечения
дополнительной
задержки
между
предшествующим
и
последующим
кадрами
данных или
кадрами
удаленного
запроса
данных.
Кадры
данных и
кадры
удаленного
запроса
данных
отделяются
от
предшествующих
кадров
межкадровым
пространством.
3.1
Кадр данных
(DATA FRAME)
Кадр
данных
состоит из 7
различных
полей: «Начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
данных», «поле
CRC», «поле
подтверждения»,
«конец
кадра».
Начало
кадра (Start of Frame)
Отмечает
начало
кадра
данных или
кадра
удаленного
запроса
данных.
Состоит из
бита с лог. ‘0’.
Узлу
разрешено
начинать
передачу
только при
свободной
шине (см.
простой
шины). Все
узлы должны
быть
синхронизированы
по началу
фронта,
вызванного
полем «начало
кадра» (см.
аппаратная
синхронизация)
узла,
начавшего
работу
первым.
Поле
арбитража
(Arbitration Field)
Состоит из
идентификатора
и RTR-бита.
CRC-последовательность
(CRC Sequence):
Для
вычисления CRC
полинома,
полином,
коэффициенты
которого
задаются
потоком,
состоящим
из значений,
бит полей: «начало
кадра «, «поле
арбитража»,
«поле
контроля», «поле
данных» (если
имеется) (самые
младшие 15
коэффициентов
полинома =0),
должен быть
разделён
полином
следующего
вида:
x^15+x^14+x^10+x^8+x^7+x^4+x^3+1
Остаток
этого
полиномиального
деления
есть CRC-последовательность,
передаваемая
по шине.
CRC-разделитель
(CRC Delimiter):
CRC-последовательность
сопровождается
CRC-разделителем,
который
всегда
равен лог. «1».
Поле
подтверждения
(ACK FIELD)
Длина
2 бита.
Содержит
область
подтверждения
(1 бит) и
разделитель
подтверждения
(1 бит). В поле
подтверждения
передающий
узел
посылает
два бита с
лог. «1».
Приемник,
получивший
правильное
сообщение,
информирует
об этом
передатчик,
посылая бит
с лог. «0» (т.е.
перезаписывая
бит в
области
подтверждения
с лог. «1» на
бит с лог. «0»).
Область
подтверждения
(ACK Slot)
Все
узлы,
получившие
соответствующую
CRC-последовательность,
сообщают об
этом внутри
области
подтверждения
перезаписью
бита с лог. «1»
на бит с лог.
«0».
Разделитель
подтверждения
(ACK Delimiter)
Второй
бит области
подтверждения
должен быть —
лог. «1».
Следовательно,
область
подтверждения
окружена
битами с лог.
«1» (CRC-разделитель
и
разделитель
подтверждения).
Конец
кадра (END OF FRAME)
Каждый
кадр данных
и кадр
удаленного
запроса
данных
разграничены
последовательностью
флагов,
состоящей
из семи
битов с лог.
«1».
3.2
Кадр
удаленного
запроса
данных (REMOTE FRAME)
Узел
может
инициализировать
передачу
кадра
данных
другим
узлом,
посылая
кадр
удаленного
запроса
данных.
Этот кадр
состоит из 6
полей:
«Начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
CRC», «поле
подтверждения»,
«конец
кадра».
В отличие от
кадра
данных , RTR бит =
«1». Здесь нет
поля данных,
зависящего
от значения
«кода длины
данных»,
внутри
этого поля
может быть
записано
любое из
допустимых
значений (0��.8).
Полярность RTR
бита
показывает,
является ли
передаваемый
кадр кадром
данных или
кадром
удаленного
запроса
данных
3.3.
Кадр ошибки
(ERROR FRAME)
Состоит
из двух
различных
полей.
Первое поле
является
суперпозицией
флагов
ошибки
различных
узлов,
второе поле —
поле
разделителя
ошибки.
Для
корректного
завершения
кадра
ошибки, узлу
в состоянии
«пассивной
ошибки»
может быть
необходим
доступ к
шине,
поэтому
шина должна
быть
свободной,
по крайней
мере, три
времени
передачи
бита.
Следовательно,
шина не
должна быть
загружена
на 100%.
Флаг
ошибки (Error Flag):
Существует
2 формы флага
ошибки:
активный и
пассивный
флаг ошибки.
1.
активный
флаг ошибки
состоит из 6
последовательных
бит с лог. «0».
2.
пассивный
флаг ошибки
состоит из 6
последовательных
бит с лог. «1,
если они не
перезаписаны
битами с лог.
«0» других
узлов.
Узел в
состоянии «активной
ошибки» при
обнаружении
ошибки
передает
активный
флаг ошибки.
Форма флага
ошибки
нарушает
закон
кодирования
битового
потока
методом
разрядного
заполнения (см.
раздел «Кодирование
битового
потока»).
Вследствие
этого все
узлы
обнаруживают
условие
ошибки и
начинают
передавать
флаг ошибки.
В
результате,
последовательность
бит с лог. «0»,
контролируемая
на шине
является
суперпозицией
флагов
ошибок
отдельных
узлов. Общая
длина этой
последовательности
— от 6 до 12 бит с
лог. «0».
Узел в
состоянии «пассивной
ошибки» при
обнаружении
ошибки
передает
пассивный
флаг ошибки,
он ждет
последовательности
из 6
одинаковых
бит,
определяющих
начало
флага
пассивной
ошибки.
Когда эта
последовательность
будет
обнаружена,
флаг
пассивной
ошибки
будет
завершен.
Разделитель
ошибки (Error Delimiter)
Разделитель
ошибки
состоит из 8
бит с лог. «1».
После
передачи
флага
ошибки
каждый узел
посылает
биты с лог. «1»
и
контролирует
шину, пока не
обнаружит
бит с лог. «1».
Впоследствии
он начинает
передавать 7
бит с лог. «1».
3.4.
Кадр
перегрузки
(OVERLOAD FRAME)
Кадр
перегрузки
содержит
два битовых
поля: флаг
перегрузки
и
разделитель
перегрузки.
Имеются
два вида
перегрузки,
которые оба
приводят к
передаче
кадра
перегрузки.
1.
Внутреннее
состояние
приёмника,
которое
требует
задержки
следующего
кадра
данных или
кадра
удаленного
запроса
данных.
2.
Обнаружение
бита с лог. «0»
в течение
поля
перерыва (см.
межкадровое
пространство).
Передача
кадра
перегрузки
из-за
состояния 1
возможна
только в
первом
битовом
интервале
перерыва, в
то время как
кадры
перегрузки
по
состоянию 2
начинают
передаваться
на
следующем
битовом
интервале
после
обнаружения
бита с лог. «0».
Для больших
задержек
может быть
послано
несколько
кадров
перегрузки.
Флаг
перегрузки
(Overload flag)
Состоит
из 6 бит с лог.
«0». Формат
соответствует
активному
флагу
ошибки.
Форма флага
перегрузки
нарушает
фиксированную
форму поля
перерыва.
Поэтому,
другие узлы
также
обнаруживают
состояние
перегрузки
и в свою
очередь
начинают
передавать
флаг
перегрузки.
В случае
обнаружения
бита с лог. «0»
в течение
третьего
бита
перерыва,
некоторые
узлы не
будут
корректно
интерпретировать
флаг
перегрузки,
первый (из
шести) бит с
лог. «0» будет
принят за
поле «начало
кадра».
Шестой бит
флага
перегрузки
с лог. «0»
нарушает
закон
кодирования
битового
потока
методом
разрядного
заполнения (см.
раздел «Кодирование
битового
потока
методом
разрядного
заполнения»).
Разделитель
перегрузки
(Overload Delimiter)
Состоит
из 8 бит с лог.
«1».
Разделитель
перегрузки
имеет такую
же форму, как
и
разделитель
ошибки.
После
передачи
флага
перегрузки
узел
контролирует
шину, пока не
обнаружит
бит с лог. «1».
В этой точке
времени все
узлы уже
закончили
передавать
флаг
перегрузки
и начинают
передавать 7
бит с лог. «1».
4.
Межкадровое
пространство
(INTERFRAME SPACE)
Кадры
данных и
кадры
удаленного
запроса
данных
отделяются
от
предшествующих
кадров
любого типа (кадра
данных,
кадра
удаленного
запроса
данных,
кадра
ошибки,
кадра
перегрузки).
Это
разделяющее
битовое
поле
называется
межкадровым
пространством.
Кадрам
перегрузки
и кадрам
ошибки не
предшествует
межкадровое
пространство;
несколько
кадров
перегрузки
также не
отделяются
межкадровым
пространством.
Межкадровое
пространство
содержит
поля «перерыв»
и «простой
шины», и для
узла в
состоянии «пассивной
ошибки»,
который был
передатчиком
предыдущего
сообщения,
дополнительное
поле — «приостановка
передачи» (поле
«приостановка
передачи»
находится
между
полями «перерыв»
и «простой
шины»).
Поле
перерыва (Intermission)
Состоит
из 3 бит с лог.
«1». В течение
перерыва
никакому
узлу нельзя
начинать
передачу
кадра
данных или
кадра
удаленного
запроса
данных.
Единственно
возможное
действие —
это
сигнализация
состояния
перегрузки.
Простой
шины (Bus Idle)
Простой
шины может
иметь
произвольную
длину. Если
шина
опознана
как
свободная,
любой узел,
который
имеет что —
либо для
передачи
может
начать
передачу.
Сообщение,
которое
было
задержано
для
передачи
другого
сообщения,
начинает
передаваться
в первом
бите после
поля
перерыва.
Обнаружение
бита с лог. «0»
на шине в
течение
этого поля
интерпретируется
как поле «начало
кадра».
Приостановка
передачи
Узел
в состоянии
«пассивной
ошибки»,
после
передачи
сообщения,
посылает 8
бит с лог. «1»
после поля
перерыва,
перед
началом
передачи
дальнейших
сообщений
или
определением
занятости
шины. Если
тем
временем
началась
передача (вызванная
другим
узлом), узел
станет
приёмником
этого
сообщения.
5.
Определение
передатчика
/ приемника
Передатчик
Узел,
передающий
сообщение
называется
передатчиком
этого
сообщения.
Узел
является
передатчиком
до тех пор,
пока он не
потерял
арбитраж.
Приёмник
Узел
называется
приёмником
сообщения,
если он не
передатчик
сообщения и
шина занята.
6.
Корректность
сообщения
Точка
времени, в
которой
сообщение
является
корректным,
различна
для
передатчиков
и
приёмников
сообщений.
Передатчик
Сообщения
пригодно
для
передатчика,
если нет
ошибок до
конца кадра.
Если
сообщение
разрушено,
ретрансляция
будет
происходить
автоматически
и согласно
приоритетам.
Чтобы
решить
приоритеты
доступа к
шине с
другими
сообщениями,
ретрансляция
должна
начаться,
как только
шина
освободится.
Приёмник
Сообщение
корректно
для
приёмника,
если нет
ошибок до
конца кадра.
7.
Кодирование
битового
потока
Следующие
поля: «начало
кадра», «поле
арбитража»,
«поле
контроля», «поле
данных» и «поле
CRC»
кодированы
методом
разрядного
заполнения.
Всякий раз,
когда
передатчик
передает
пять
последовательных
бит
идентичной
величины в
битовом
потоке, он
автоматически
вставляет
дополняющий
бит
противоположного
значения в
фактически
передаваемый
битовый
поток.
Оставшиеся
битовые
поля кадра
данных или
кадра
удаленного
запроса
данных («разделитель
CRC», «поле
подтверждения»
и «конец
кадра»)
имеют
фиксированную
форму и не
кодируются.
Кадр ошибки
и кадр
перегрузки
также имеют
фиксированную
длину и не
кодируются
методом
разрядного
заполнения.
8.
Обработка
ошибок
Существует
пять типов
не
взаимоисключающих
ошибок:
- разрядная
ошибкаУзел,
который
посылает
что — либо на
шину также
контролирует
шину.
Разрядная
ошибка
может быть
обнаружена
во время
передачи
бита, если
переданное
значение
отличается
от
значения,
прочитанного
с шины.
Исключение:
При
посылке
бита с лог.
«1» в
течение
поля
арбитража
или
области
подтверждения
разрядная
ошибка не
возникает,
если
контролируется
бит с лог. «0».
Передатчик,
посылающий
флаг
пассивной
ошибки и
обнаруживший
бит с лог. «0»
не
интерпретирует
его как
разрядную
ошибку. - ошибка
заполненияОшибка
заполнения
обнаруживается
во время
приема
последовательности
из шести
бит
одинакового
разрядного
уровня в
поле
сообщения,
которое
должно
быть
кодировано
методом
разрядного
заполнения. - ошибка CRC
Последовательность
CRC состоит из
результата
вычисленного
передатчиком.
Приёмники
вычисляют CRC
таким же
образом,
как и
передатчик.
Ошибка CRC
обнаруживается
при
несовпадении
расчетного
результата
CRC —
последовательности
в
приёмнике
и
присланной
CRC —
последовательности
передатчика. - ошибка
форматаОшибка
формата
обнаруживается,
когда
разрядное
поле
фиксированного
формата
содержит
один или
несколько
лишних бит. - ошибка
подтвержденияОшибка
подтверждения
обнаруживается
передатчиком
всякий раз,
когда нет
контроля
бита с лог.
«0» в
течение
области
подтверждения.9.
Сигнализация
ошибокУзел,
обнаруживший
состояние
ошибки
сигнализирует
об этом
передачей
флага
ошибки. Для
узла в
состоянии «активной
ошибки» это
передача
флага
активной
ошибки, для
узла в
состоянии «пассивной
ошибки» это
передача
флага
пассивной
ошибки.
Всякий раз
при
обнаружении
разрядной
ошибки,
ошибки
заполнения,
ошибки
формата и
ошибки
подтверждения
узел
начинает
передавать
флаг
ошибки в
следующем
бите.
Всякий раз,
когда
обнаружена
ошибка CRC,
передача
флага
ошибки
будет
начата
после
разделителя
подтверждения,
если не
была
начата
передача
флага
ошибки для
другого
состояния.10.
Типизация
ошибокУзел
может быть
в одном из
трех
состояний: - активной
ошибки - пассивной
ошибки - отключения
от шины
В
состоянии «активной
ошибки»
узел может
взаимодействовать
с шиной,
посылая
флаг
активной
ошибки при
обнаружении
ошибки. В
состоянии «пассивной
ошибки»
узел не
должен
слать флаг
активной
ошибки. Он
принимает
участие во
взаимодействии
с шиной, но
при
обнаружении
ошибки
должен
послать
флаг
пассивной
ошибки.
После
передачи
сообщения
об ошибке,
узел в
состоянии «пассивной
ошибки»
будет ждать
инициализации
дальнейшей
передачи (см.
приостановка
передачи).
В состоянии
отключения
от шины узлу
не
разрешено
оказывать
влияние на
шину.
Для
типизации
ошибок у
каждого
узла — CAN есть
два
счетчика:
1.
счетчик
ошибок
передачи
2.
счетчик
ошибок
приема
(Прим.
переводчика:
Правила
модификации
счетчиков
здесь не
приводятся.
Но хочется
обратить
внимание на
то, что при
наличии
ошибок,
счетчики
увеличиваются
быстрей, чем
уменьшаются
при приемах
или
передачах
без ошибок).
Узел
находится в
состоянии «пассивной
ошибки»,
если
счетчик
ошибок
передачи и /
или счетчик
ошибок
приема
больше или
равен 128.
Узел
отключается
от шины, если
счетчик
ошибок
передачи
или приема
больше или
равен 256.
Узел,
находившиеся
в состоянии
«пассивной
ошибки»
переходит в
состояние «активной
ошибки»,
если
счетчик
ошибок
передачи и
счетчик
ошибок
приема
меньше или
равен 127.
Узлу,
который
находится в
состоянии «отключения
от шины»,
разрешается
перейти в
состояние «активной
ошибки», с
установкой
обоих
счетчиков в 0,
после того,
как на шине
будут
проконтролированы
128
прохождений
11
последовательных
битов с лог.
«1».
Обратите
внимание:
1.
Величина
счетчика
ошибки
большая, чем
96 указывает
на
серьезные
нарушения
на шине. Это
можно
использовать
для
проверки
состояния
шины.
2. Запуск /
Пробуждение:
Если в
некоторый
момент
времени
активен
только один
узел, и если
этот узел
передает
некоторое
сообщение,
он не
получит
подтверждения,
обнаруживается
ошибка и
происходит
повтор
сообщения.
Из-за этого
он может
перейти в
состояние «пассивной
ошибки», но
не может
перейти в
состояние «отключения
от шины».
10.
Требования
к
синхронизации
Номинальная
скорость
передачи
информации
в битах
Номинальная
скорость
передачи
информации
в битах —
число битов
за секунду,
передаваемое
в
отсутствии
пересинхронизации
идеальным
передатчиком.
Номинальное
время
передачи
бита
номинальное
время
передачи
бита = 1 /
номинальную
скорость
передачи
информации
Номинальное
время
передачи
бита можно
представить
как время,
разделенное
на
отдельные
не
перекрывающиеся
сегменты
времени. Это
сегменты:
—
Сегмент
синхронизации
(SYNC_SEG)
—
Сегмент
времени
распространения
(PROP_SEG)
—
Сегмент TSEG1 (PHASE_SEG1)
—
Сегмент TSEG2 (PHASE_SEG2)
SYNC SEG
Эта
часть
времени
передачи
бита
используется,
чтобы
синхронизировать
различные
узлы на шине.
Ожидается,
что фронт
сигнала
находится
внутри
этого
сегмента.
PROP SEG
Эта
часть
времени
передачи
бита
используется,
чтобы
компенсировать
физическую
задержку
времён
внутри сети.
Это
удвоенная
сумма
времени
распространения
сигнала по
шине,
входной
задержки
компаратора,
и выходной
задержки
формирователей.
TSEG1 и TSEG2.
Эти
сегменты
используются,
чтобы
компенсировать
ошибки
смещения
фазы
сигнала. Эти
сегменты
могут быть
удлинены
или
укорочены
пересинхронизацией.
Точка
считывания
(Sample point)
Точка
считывания —
точка
времени, в
которой
уровень
шины
читается и
интерпретируется,
как
величина
соответствующего
бита. Ее
место — в
конце TSEG1.
Время
обработки
информации
Время
обработки
информации —
отрезок
времени,
начинающийся
с точки
считывания,
зарезервированный
для
вычисления
уровня бита.
Квант
времени
Квант
времени —
фиксированная
единица
времени,
полученная
из периода
генератора.
Существует
программируемый
делитель,
оперирующий
целочисленными
величинами,
изменяющимися,
по крайней
мере, от 1 до 32.
Начиная с
минимального
кванта
времени,
квант
времени
может иметь
длительность:
квант
времени = m *
минимальный
квант
времени ,где m
— величина
делителя.
минимальный
квант
времени = 1 / f
генератора.
Длительность
отрезков
времени
- SYNC_SEG — 1 квант
времени . - PROP_SEG —
программируем,
1,2, …, 8 квантов. - TSEG1 —
программируем,
1,2, …, 8 квантов. - TSEG2 — максимум
из TSEG1 и
времени
обработки
информации - время
обработки
информации
— меньше или
равно 2
квантам.
12.
Синхронизация
Аппаратная
синхронизация
После
аппаратной
синхронизации
внутреннее
время
передачи
бита
перезапускается
с SYNC_SEG. Таким
образом,
аппаратная
синхронизация
вынуждает
фронт
находиться
внутри
сегмента SYNC_SEG.
Ширина
перехода
пересинхронизации
В
результате
пересинхронизации
TSEG1 может быть
удлинен, или
TSEG2 может быть
сокращен.
Количество
удлинения
или
сокращения
сегментов TSEGx
(x=1,2) имеет
верхний
предел,
связанный с
шириной
перехода
пересинхронизации.
Ширина
перехода
пересинхронизации
должна быть
программируема
между 1 и min(4, TSEG1).
Синхронизация
информации
может быть
получена из
переходов
от одного
бита к
другому.
Максимальная
длина между
двумя
переходами,
которые
могут
использоваться
для
пересинхронизации
— 29 времен
передачи
бита.
Фазовая
ошибка
фронта
Фазовая
ошибка
фронта
определяется
позицией
фронта
относительно
SYNC_SEG,
измеряется
в квантах
времени.
Знак
фазовой
ошибки
определяется
следующим
образом:
- e = 0, если
фронт
сигнала
находится
внутри SYNC_SEG. - e> 0, если
фронт
сигнала
перед
точкой
считывания. - e < 0, если
фронт
сигнала
после
точки
считывания
предыдущего
бита.
Пересинхронизация
Эффект
пересинхронизации
— также как и
от
аппаратной
синхронизации,
когда
величина
фазовой
ошибки
фронта
сигнала,
которая
вызывает
пересинхронизацию
— меньше или
равна
программируемой
величине
ширины
перехода
пересинхронизации.
Когда
величина
ошибки фазы
больше чем
ширина
перехода
пересинхронизации,
- и если
ошибка
фазы
положительна,
то TSEG1
удлиняется
на время
равное:
время
передачи
бита *
ширину
перехода
пересинхронизации. - и если
ошибка
фазы
отрицательна,
то TSEG2 —
сокращается
на время
равное:
время
передачи
бита *
ширину
перехода
пересинхронизации.
Правила
синхронизации
Синхронизация
и
пересинхронизация
— две формы
синхронизации.
На них
действуют
следующие
правила:
1.
Позволяется
только одна
синхронизация
внутри
одного
интервала
передачи
бита.
2. Для
синхронизации
будет
использоваться
фронт
только, если
величина,
полученная
в
предыдущей
точке
считывания (предыдущая
величина на
шине)
отличается
от величины
на шине
сразу после
фронта.
3.
Синхронизация
выполняется
всякий раз,
по фронту «1»
-> «0» в
течение
простоя
шины.
4. Все
другие
фронты «1» ->
«0» (и фронты
«0» -> «1» в
случае
низких
скоростей),
выполняемые
по правилам 1
и 2, будут
использоваться
для
пересинхронизации.
|
CAN 2.0 В |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1. CAN — Область Задача
Обратите Область
Область Внутри 2.
Послойная
Сообщения Информация Информационная В Гибкость Маршрутизация Групповая Непротиворечивость Скорость Скорость Приоритеты Идентификатор Удаленный Посылая Multimaster Когда Арбитраж Всякий Безопасность Для Обнаружение Для Эффективность Сигнализация Искаженные Типизация Узлы Подключение Последовательная Канал Шина Уровни Шина Подтверждение Все Режим Для Генератор Требования 3. Форматы
Типы Кадр Кадр Кадр
Начало Начало Поле Формат
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Идентификатор Идентификатор Идентификатор Base ID Base ID Extended ID Extended ID Бит Бит Бит Заменитель Бит Бит Поле Поле
Код Число |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Допустимое Поле Поле Поле Последовательность Последовательность Последовательность Поле Поле Область Все Разделитель Разделитель Конец Каждый Кадр Узел, Кадр Кадр
Для Флаг Имеются Разделитель Разделитель Кадр Кадр Флаг Состоит Замечание: Разделитель Состоит Межкадровое Кадры Межкадровое
Перерыв Состоит Замечание: Если Простой Период Приостановка После Стандартный Стандартный Определение Передатчик: Приемник: 4. Фильтрация Если 5. Момент Передатчик: Приемник: 6. Кодирование 7. Обнаружение
Передача Узел, Всякий Всякий 8. Неисправный
Узел в Для Замечание: Замечание: 9. Для Замечание: 10. Номинальная Номинальная номинальное Номинальное
Сегмент Используется Сегмент Используется, Сегменты Эти Точка Момент Время Время Шаг Шаг шаг Длительность
Общее 11. После Переход В Перехода Ошибка Ошибка
12. Эффект
Правила Аппаратная |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CAN |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
CAN OSI модель
|
| CANopen | DeviceNet | SDS (V2.0) | |
| Name of Communication Object | Process Data Object | I/O-Message | Multicast Channel APDU |
| Maximal Number of Communication Objects per Device | 512 Transmit PDOs 512 Receive PDOs | 27 I/O- Transmit Messages 1701 I/O Receive Messages per device 32 Multicast Channels for each of up to |
32 Embedded Objects per device |
| Maximal length of Data Field | 8 bytes | 8 bytes fragmented: Arbitrary length | 6 bytes fragmented: 64 * 4 bytes |
| Protocol | Unfragmented: No overhead, Notify/Read «Stored-Event»-protocol (CAL/CMS) Unacknowledged |
Unfragmented: No overhead, three «Transport Classes» supported:
|
Unfragmented: 2 byte protocol overhead, Unacknowledged |
| Fragmented: Unacknowledged fragmented protocol 1 byte protocol overhead per frame |
Fragmented: Acknowledged fragmented protocol with Acknowledge after reception of complete block 4 bytes protocol overhead per fragment |
||
| Message Production Triggering Modes |
|
|
Specified by object model |
| Mapping of Application Objects | Maximum number of mappable application objects/PDO dependent on data size of objects (1-bit objects: 64 application objects mappable) Definition of Application objects by means of «Mapping Parameter Record» (configurable) Dynamic mapping supported |
Arbitrary number of Application objects mappable with fragmented protocol. Definition of Application objects by means of Assembly Object (several Assembly Objects possible) Dynamic mapping supported |
Network Data Descriptor defines size, granularity and data type of I/O data of Embedded |
Вызов (triggering)
сообщений
Все
рассматриваемые
протоколы
поддерживают
различные
способы
вызова
сообщений.
DeviceNet
поддерживает
циклический
(Cyclic), по
состоянию
(Change-of-State) и
программный
(Application) способы
вызова.
Циклический
вызов
осуществляется
по
истечению
времени
таймера и
начинается
передача
сообщения.
Передача
по
состоянию
начинается,
когда
статус
определенного
объекта
изменяется.
В этом
случае
сообщение
также
передается,
когда
истекает
определенный
интервал
времени, в
котором не
осуществлялась
передача
сообщения.
Программным
способом
сам объект
решает,
когда
начать
передачу
сообщения.
В этом
случае
сообщение
также
передается,
когда
истекает
определенный
интервал
времени
без
передачи
сообщения.
Установление
соответствий
(mapping) для
программных
объектов
Сетевые
устройства
обычно
содержат
более
одного
программного
объекта и
передача I/O
сообщения
более чем
одному
программному
объекту
внутри
одного PDO
является
необходимым
требованием.
В DeviceNet
объединение
прикладных
данных
осуществляется
посредством
трансляционных
(assembly) объектов,
которые
определяют
формат
передаваемых
данных.
Устройство
может
содержать
более
одного I/O
трансляционного
объекта и
выбор
подходящего
(consumed/ produced_connection_path)
может быть
настраиваемой
опцией
устройства.
Прямые
(peer-to-peer)
коммуникационные
каналы
Для
конфигурации
устройств
посредством
конфигурационных
средств
требуются
специальные
функции у
устройств
или
программы,
обеспечивающие
многоцелевые
каналы
связи. Это
не
критичные
по времени
каналы
связи.
Передача
данных в
них
осуществляется
посредством
протокола
с
подтверждениями
и
фрагментацией.
Любой из
протоколов
высокого
уровня,
которые
поддерживают
некоторую
конфигурацию
устройств,
должны
обеспечивать
этот вид
связи.
DeviceNet
обеспечивает
многоцелевые
устройство
ориентированные
каналы и
сервисы.
Запись и
чтение
атрибутов
объектов,
контролирование
объектов (reset,
start, stop etc.),
сохранение/восстановление
атрибутов
объектов
осуществляется
посредством
явных (Explicit)
сообщений.
Намерение
использовать
данное
сообщение
определяется
в поле
данных CANа.
На рис. 7
показан
формат
поля
данных
фрагментированного
Explicit
сообщения.
В запросе
сервиса
указывается
номер
класса,
номер
экземпляра(instance),
номер
атрибута (в
поле Service specific arguments).
Рис. 6. DeviceNet Fragemented
Explicit Message Data Field Format (Request/Response)
Explicit(прямая)
связь
устанавливается
посредством
менеджера
сообщений
(Unconnected Message Manager (UCMM)). UCMM
предоставляет
два
сервиса
для
открывания
и
закрывания
подобных
соединений.
Каждое
устройство,
поддерживающее
UCMM,
резервирует
у себя
идентификаторы
сообщений
для
запросов и
ответов
для UCMM. Для
устройств 2-й
группы,
которые не
поддерживают
UCMM порт, master
устройство
сперва
должно
разместить
Explicit
соединение
в
предопределенном
множестве
соединений.
Запрос к
устройству
группы 2
передается
как Explicit
запрос без
предварительного
установления
соединения
(Unconnected Explicit Request ) с
зарезервированным
идентификатором
сообщения.
Сравнительные
характеристики
протоколов
CANopen, DeviceNet и SDS в
отношении
прямых (peer-to-peer)
коммуникационных
каналов
представлены
в таблице 2.
Таблица
2. Main Characteristics of Peer-to-Peer Communication Channels
| CANopen | DeviceNet | SDS (V2.0) | |
| Name | Service Data Channel | Explicit Message | Peer-to-peer Channel |
| Maximum number of channels | 128 Client SDOs, 128 Server SDOs per device | 27 Explicit Transmit Messages 1701 Explicit Receive messages per device |
4 channels per Embedded Object. 32 Embedded Objects per Logical Device |
| Protocol | < 5 byte: Acknowledged unfragmented 4 byte: Fragmented transmission (7 bytes per fragment) Each frame acknowledged Any length (CAL Multiplexed Domain protocol) |
< 7 byte: Acknowledged unfragmented 6 byte: Fragmented transmission. (6 bytes per fragment) Each frame acknowledged Any length |
< 6 bytes Acknowledged unfragmented 5 byte Fragmented transmission (3 bytes per fragment) Acknowledgement of complete data block. Max. 255 byte |
| Establishing of Connections |
|
|
|
| Connection Services and Arguments | Initiate, Abort Upload/Download Segment/Domain | Open/Close Creation, Configuration, Start, Stop, Reset etc. of Objects |
Open/Close Read, Write, Event, Action |
| Index and Subindex of addressed | Object Directory Entry Object attribute access path, Service arguments |
Channel Number, Attribute/Action/Event Identifier |
Установление
связей для
обмена
данных
процесса
Распределение
идентификаторов
для
передаваемых
сообщений
и ,
соответственно,
получаемых
сообщений
устанавливает
коммуникационные
пути в CAN
сети.
Установление
взаимодействия
возможно
через
использование
предопределенного
множества
сообщений
с уже
размещенными
идентификаторами
сообщений
или через
переменное
распределение
идентификаторов
для
сообщений.
В
системе с
предопределенным
множеством
сообщений
«функции»
и
идентификаторы
сообщений
уже
определены.
DeviceNet также
использует
предопределенное
множество
сообщений
для
системы со
структурой
1:n. Master
устройство,
предварительно
разместив
у себя
множество
связей со Slave
устройствами,
«знает» ID
сообщений
для
передачи
запроса и ID
сообщений
для
получения
ответа,
который
включает Slave
MAC-ID в
соответствии
с
предопределенным
множеством
связей.
Также
возможно
не
предопределять
идентификаторы
сообщений.
Сетевое
управление
Так
как в CAN-сети
мы имеем
дело с
распределенными
приложениями,
должны
отслеживаться
определенные
события(отказы
различных
частей
приложения
или отказ
устройств).
Поэтому
главными
задачами
сетевого
управления
становятся
обнаружение
и вывод
ошибок в
сети и
предоставление
сервисов,
позволяющих
контролировать
статусы
устройств
и вести
координацию
устройств.
В
зависимости
от
системных
решений
сетевое
управление
может
вестись
явным или
косвенным
путем.
В DeviceNet
каждое
соединение
контролируется.
Поэтому
каждая
ожидающая
сообщение
конечная
точка
имеет «Inactivity/Watchdog»
таймер,
чтобы
контролировать
прибытие
сообщения
согласно
предопределенному
времени
ожидания.
Если время
истекает,
соединение
выполняет
действие
«Timeout». На рис. 7
показана
диаграмма
изменения
состояний
у объекта I/O.
Рис. 7. Device Net I/O
Connection Object State Transition Diagram
После
получения
вызова CREAT ( Explicit
сообщение)
соединение
настраивается
при помощи
подходящей
последовательности
вызовов
явных
сообщений
и после
этого
устанавливается.
Перед
получением
доступа к
сети
каждое
устройство
должно
совершить
проверку
на
дубликат
своего MAC-ID.
Определенные
алгоритмы
выбора
гарантируют
уникальность
MAC-ID.
Контроль
может
осуществляться
также
посредством
Heartbeat
сообщения,
которое
может
посылаться
устройствам
посредством
UCMM в форме
сообщения.
В поле
данных
этого
сообщения
передается
состояние
устройства.
Heartbeat
сообщение
вызывается
объектом Idendity.
Профайлы
устройств
Для
открытых
автоматических
систем
помимо
обеспечения
связи от
входящих в
их состав
устройств
требуется
также
обеспечение
возможности
взаимодействия
и
взаимозаменяемости.
Поэтому
протоколы
высокого
уровня (такие
как DeviceNet)
описывают
функциональные
возможности
устройств
в виде
модели
устройства
(«Device Model»).
Помимо
описания
функциональности
устройств
модель
устройства
должна
также
содержать
ряд важных
параметров
(статус,
диагностическую
информацию,
коммуникационные
возможности,
конфигурационные
параметры
и т.д.). На рис. 8
показана
модель
устройства
DeviceNet.
Рис. 8. DeviceNet Object Model
DeviceNet
профайл
должен
содержать
следующую
информацию:
- модель
объекта
для
устройства - формат
данных I/O
для
устройства - конфигурационные
данные и
внешние
интерфейсы
для этих
данных
В
таблице 3
показаны
главные
функции
объектов в
DeviceNet.
Таблица
3. Objects of a DeviceNet node
| Object | Function |
| Connection | Instantiates connections (I/O or Explicit Messaging) |
| DeviceNet | Maintains configuration and status of physical attachments to DeviceNet. |
| Message Router | Routes received Explicit Messages to appropriate target objects |
| Assembly | Groups attributes of multiple objects into a single block of data, which can be sent and received over a single connection |
| Parameter | Provides a standard means for device configuration and attribute access |
| Identity | Provides general information about the identity of a device |
| Application | Supplies application-specific behaviour and data |
Заключение
Протокол
CAN
применяется
в real-time
системах
для
решения
различных
задач. В
настоящий
момент
развиваются
несколько
видов CAN
протоколов
высокого
уровня,
таких как CAL
,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в
основе
которых
лежит
канальный
протокол CAN2.0
(Bosch) , и на
основе
этих
протоколов
можно
решать
проблемы,
возникающие
в real-time
системах,
которые
невозможно
разрешить
при помощи
других
известных
протоколов,
скажем, TCP/IP.
Need a practical intro to CAN bus errors?
In this tutorial you’ll learn about the basics of CAN error handling, the 5 CAN bus error types, the CAN
error frame and CAN node error states.
To get practical, we’ll also generate & record CAN errors in 6 experiments.
In this article
- What are CAN bus errors?
- The CAN error frame
- 5 CAN error types
- States & error counters
- 6 practical experiments
- LIN bus errors
- CAN error logging use cases
- FAQ
What are CAN bus errors?
As explained in our simple intro
to CAN
bus, the Controller Area Network is today the de facto standard across automotives and industrial
automation
systems.
A core benefit is the robustness of CAN, making it ideal for safety critical
applications.
Here, it is worth noting:
Error handling is vital to the robustness of CAN.
CAN bus errors can occur for several reasons — faulty cables, noise, incorrect termination, malfunctioning
CAN nodes etc. Identifying, classifying and resolving such CAN errors is key to ensuring the continued
performance of the overall CAN system.
In particular, error handling identifies and rejects erroneous messages, enabling a sender to
re-transmit the message. Further, the process helps identify and disconnect CAN nodes that
consistently transmit erroneous messages.
How does CAN error handling work?
Error handling is a built-in part of the CAN standard and every CAN controller. In other words, every
CAN node handles fault identification and confinement identically. Below we’ve made a simple illustrative example:
- CAN node 1 transmits a message onto the CAN bus — and reads every bit it sends
- In doing so, it discovers that one bit that was sent dominant was read recessive
- This is a ‘Bit Error’ and node 1 raises an Active Error Flag to inform other nodes
- In practice, this means that node 1 sends a sequence of 6 dominant bits onto the bus
- In turn, the 6 dominant bits are seen as a ‘Bit Stuffing Error’ by other nodes
- In response, nodes 2 and 3 simultaneously raise an Active Error Flag
- This sequence of raised error flags comprise part of a ‘CAN error frame’
- CAN node 1, the transmitter, increases its ‘Transmit Error Counter’ (TEC) by 8
- CAN nodes 2 and 3 increase their ‘Receive Error Counter’ (REC) by 1
- CAN node 1 automatically re-transmits the message — and now succeeds
- As a result, node 1 reduces its TEC by 1 and nodes 2 and 3 reduce their REC by 1
The example references a number of concepts that we will detail shortly: Error frames, error
types, counters and states.
The CAN bus error frame
In the illustrative example, the CAN nodes ‘raise Active Error Flags’, thus creating an ‘error frame’ in
response to detecting a CAN error.
To understand how this works, let us first look at a «normal» CAN frame (without errors):
CAN bus bit stuffing
Notice that we highlighted ‘bit stuffing’ across the CAN frame.
Bit stuffing is a subtle, but vital part of the CAN standard. Basically it states that whenever a CAN node
sends five bits of the same logic level (dominant or recessive), it must send one bit of the opposite level.
This extra bit is automatically removed by the receiving CAN nodes. This process helps ensure continuous
synchronisation of the network.
As per the previous example, when CAN node 1 detects an error during the transmission of a CAN message, it
immediately transmits a sequence of 6 bits of the same logic level — also referred to as raising an Active
Error Flag.
If we measure the transmission of a CAN frame via an oscilloscope and digitize the result, we can also
see the stuff bits in practice (see the red timestamp marks):
Active Error Flags
As we just learned, such a sequence is a violation of the bit stuffing rule — aka a ‘Bit Stuffing Error’.
Further, this error is visible to all CAN nodes on the network (in contrast to the ‘Bit Error’ that resulted
in this error flag being raised). Thus, the raising of error flags can be seen as a way of
«globalizing» the discovery of an error, ensuring that every CAN node is informed.
Note that the other CAN nodes will see the Active Error Flag as a Bit Stuffing Error. In
response they also raise an Active Error Flag.
As we’ll explain shortly, it is important to distinguish between the error flags. In particular, the first
error flag
(from the ‘discovering’ node) is often referred to as a ‘primary’ Active Error Flag, while
the error flags of
subsequent ‘reacting’ nodes are referred to as the ‘secondary’ Active Error Flag(s).
3 CAN error frame examples
Let’s look at three example scenarios:
Example 1: 6 bits of error flags
Here, all CAN nodes simultaneously discover that an error exists in a CAN message and raise their error
flags at the same time.
The result is that the error flags all overlap and the total sequence of dominant
bits lasts for 6 bits in total. All CAN nodes will in this case consider themselves the ‘discovering’ CAN
nodes.
This type of simultaneous discovery is less common in practice. However, it could e.g. happen as a
result of Form
Errors (such as a CRC delimiter being dominant instead of recessive), or if a CAN transmitter
experiences a bit error during the writing of a CRC field.
Example 2: 12 bits of error flags
Here, CAN node 1 transmits a dominant bit, but reads it as recessive — meaning that it discovers a Bit Error.
It immediately transmits a sequence of 6 dominant bits.
The other nodes only discover the Bit Stuffing Error
after the full 6 bits have been read, after which they simultaneously raise their error flags, resulting in
a subsequent sequence of 6 dominant bits — i.e. 12 in total.
Example 3: 9 bits of error flags
Here, CAN node 1 has already transmitted a sequence of 3 dominant bits when it discovers a Bit Error and
begins sending 6 dominant bits.
Once halfway through the primary Active Error Flag, nodes 2 and 3 recognize
the Bit Stuffing Error (due to the 3 initial dominant bits being followed by another 3 dominant bits) and
they begin raising their error flags. The result is that the sequence of dominant bits from error flags
becomes 9 bit long.
The above logic of raising error flags is reflected in what we call an ‘active’ CAN error frame.
Note in particular how the secondary error flags raised by various nodes overlap each other — and how the
primary and secondary flags may overlap as well. The result is that the dominant bit sequence from raised
error
flags may be 6 to 12 bits long.
This sequence is always terminated by a sequence of 8 recessive bits, marking the end of the error frame.
In practice, the active error frame may «begin» at different places in the erroneous CAN frame, depending on
when the
error is discovered. The result, however, will be the same: All nodes discard the erroneous CAN frame and
the
transmitting node can attempt to re-transmit the failed message.
Passive Error Flags
If a CAN node has moved from its default ‘active’ state to a ‘passive’ state (more on this shortly), it will only be
able to raise so-called ‘Passive Error Flags’. A Passive Error Flag is a sequence of 6 recessive bits as seen below.
In this case it’s relevant to distinguish between a Passive Error Flag raised by a transmitting node and a receiving
node.
Example 4: Transmitter is Error Passive
As shown in the illustration (Example 4), if a transmitter (such as CAN node 1 in our example) raises a
Passive Error Flag (e.g. in response to a Bit Error), this will correspond to a consecutive sequence of 6
recessive bits.
This is in turn detected as a Bit Stuffing Error by all CAN nodes. Assuming the other CAN
nodes are still in their Error Active state, they will raise Active Error Flags of 6 dominant bits. In other
words, a passive transmitter can still «communicate» that a CAN frame is erroneous.
Example 5: Receiver is Error Passive
In contrast, if a receiver raises a Passive Error Flag this is in practice «invisible» to all other CAN nodes
on the bus (as any dominant bits win over the sequence of recessive bits) — see also Example 5.
Effectively,
this means that an Error Passive receiver no longer has the ability to destroy frames transmitted by
other CAN nodes.
CAN error types
Next, let us look at what errors may cause CAN nodes to raise error flags.
The CAN bus protocol specifies 5 CAN error types:
- Bit Error [Transmitter]
- Bit Stuffing Error [Receiver]
- Form Error [Receiver]
- ACK Error (Acknowledgement) [Transmitter]
- CRC Error (Cyclic Redundancy Check) [Receiver]
We’ve already looked at Bit Errors and Bit Stuffing Errors briefly, both of which are evaluated at the bit
level. The remaining three CAN error types are evaluated at the message level.
Below we detail each error type:
#1 Bit Error
Every CAN node on the CAN bus will monitor the signal level at any given time — which means that a
transmitting CAN node also «reads back» every bit it transmits. If the transmitter reads a different data
bit level vs. what it transmitted, the transmitter detects this as a Bit Error.
If a bit mismatch occurs during the arbitration process (i.e. when sending the CAN ID), it is not
interpreted as a Bit Error. Similarly, a mismatch in the acknowledgement slot (ACK field) does not cause
a Bit Error as the ACK field specifically requires a recessive bit from the transmitter to be
overwritten by a dominant bit from a receiver.
#2 Bit Stuffing Error
As explained, bit stuffing is part of the CAN standard. It dictates that after every 5 consecutive bits of
the same logical level, the 6th bit must be a complement. This is required to ensure the on-going
synchronization of the network by providing rising edges. Further, it ensures that a stream of bits are not
mis-interpreted as an error frame or as the interframe space (7 bit recessive sequence) that marks the end
of a message. All CAN nodes automatically remove the extra bits.
If a sequence of 6 bits of the same logical level is observed on the bus within a CAN message (between the
SOF and CRC field), the receiver detects this as a Bit Stuffing Error aka Stuff Error.
#3 Form Error
This message-level check utilises the fact that certain fields/bits in the CAN message must always be of a
certain logical level. Specifically the 1-bit SOF must be dominant, while the entire 8-bit EOF field must be
recessive. Further, the ACK and CRC delimiters must be recessive. If a receiver finds that any of these are
bits are of an invalid logical level, the receiver detects this as a Form Error.
#4 ACK Error (Acknowledgement)
When a transmitter sends a CAN message, it will contain the ACK field (Acknowledgement), in which the
transmitter will transmit a recessive bit. All listening CAN nodes are expected to send a dominant bit in
this field to verify the reception of the message (regardless of whether the nodes are interested in the
message or not). If the transmitter does not read a dominant bit in the ACK slot, the
transmitter detects this as an ACK Error.
#5 CRC Error (Cyclic Redundancy Check)
Every CAN message contains a Cyclic Redundancy Checksum field of 15 bits. Here, the transmitter has
calculated the CRC value and added it to the message. Every receiving node will also calculate the CRC on
their own. If the receiver’s CRC calculation does not match the transmitter’s CRC, the
receiver detects this as a CRC Error.
CAN node states & error counters
As evident, CAN error handling helps destroy erroneous messages — and enables CAN nodes to retry the
transmission of
erroneous messages.
This ensures that short-lived local disturbances (e.g. from noise) will not
result in
invalid/lost data. Instead, the transmitter attempts to re-send the message. If it wins arbitration
(and there
are no errors), the message is successfully sent.
However, what if errors are due to a systematic malfunction in a transmitting node? This could
trigger an endless loop of sending/destroying the same message — jamming the CAN bus.
This is where CAN node states and error counters come in.
In short, the purpose of CAN error tracking is to confine errors by gracefully reducing the privileges of
problematic CAN nodes.
Specifically, let’s look at the three possible states:
-
Error Active: This is the default state of every CAN node, in which
it is able to
transmit data
and raise ‘Active Error Flags’ when detecting errors -
Error Passive: In this state, the CAN node is still able to
transmit data, but it now
raises
‘Passive Error Flags’ when detecting errors. Further, the CAN node now has to wait for an extra 8 bits
(aka
Suspend Transmission Time) in addition to the 3 bit intermission time before it can resume data
transmission (to
allow other CAN nodes to take control of the bus) -
Bus Off: In this state, the CAN node disconnects itself from the
CAN bus and can no
longer
transmit data or raise error flags
Every CAN controller keeps track of its own state and acts accordingly.
CAN nodes shift state depending on the value of their error counters. Specifically, every CAN node
keeps track on a Transmit Error Counter (TEC) and Receive Error Counter
(REC):
- A CAN node
enters the Error Passive state if the REC or TEC exceed 127 - A CAN node
enters the Bus Off state if the TEC exceeds 255
How do the error counters change?
Before we get into the logic of how error counters are increased/reduced, let us revisit the CAN error frame
as well
as the primary/secondary error flags.
As evident from the CAN error frame illustration, a CAN node that observes a dominant bit after its
own
sequence of 6
dominant bits will know that it raised a primary error flag. In this case, we can call this CAN
node the
‘discoverer’ of the error.
At first, it might sound positive to have a CAN node that repeatedly discovers errors and reacts promptly by
raising
an error flag before other nodes. However, in practice, the discoverer is typically also the culprit causing
errors
— and hence it is punished more severely as per the overview.
There are some additions/exceptions to the above rules, see e.g. this overview.
Most are pretty straight-forward based on our previous illustrative example. For example, it seems clear that CAN
node 1 would increase the TEC by 8 as it discovers the Bit Error and raises an error flag. The other nodes in
this
case increase their REC by 1.
This has the intuitive consequence that the transmitting node will quickly reach the Error Passive and eventually
Bus
Off states if it continuously produces faulty CAN messages — whereas the receiving nodes do not change state.
The case where a receiver raises the primary error flag may seem counter-intuitive. However, this could for
example
be the case if a receiver CAN node is malfunctioning in a way that causes it to incorrectly detect errors in
valid
CAN messages. In such a case, the receiver would raise the primary error flag, effectively causing an error.
Alternatively, it can happen in cases where all CAN nodes simultaneously raise error flags.
CAN/LIN data & error logger
The CANedge1 lets you easily
record data from 2 x CAN/LIN buses to an 8-32 GB SD card — incl. support for logging CAN/LIN errors. Simply
connect it to e.g. a car or truck to start logging —
and decode the data via free
software/APIs.
Further, the CANedge2
adds WiFi, letting you auto-transfer data to your own server — and update devices over-the-air.
learn
about the CANedge
Examples: Generating & logging error frames
We have now covered the theoretical basics of CAN errors and CAN error handling. Next, let us look at generating and
logging errors in practice. For this we will use a couple of CANedge devices — and for some tests a
PCAN-USB device.
Tip: Download the MF4 data for the tests to view the data in asammdf or CANalyzer.
download data
Test #1: No CAN bus errors
As a benchmark, we start with a test involving no CAN bus errors. Here, a CANedge2 ‘transmitter’ sends
data to another CANedge2 ‘receiver’ — and both log CAN bus errors.
By loading the MF4 log
file in the asammdf GUI we
verify that no CAN errors occurred during this test, which is to be expected.
Test #2: Removing the CAN bus terminal resistor
In this test, we remove the CAN termination in the middle of a log session. This effectively corresponds to
immediately setting the bit level to dominant. As a result, the CANedge2 transmitter immediately starts
logging Bit Errors (which occur when it attempts to transmit a recessive bit, but reads a
dominant bit). The
CANedge2 Receiver logs Bit Stuffing Errors as it detects 6 consecutive dominant bits.
These errors are
recorded until the termination is added again.
Lack of termination is rarely a practical issue if you’re recording data from a vehicle, machine etc.
However, it’s a common issue when working with ‘test bench’ setups. Here, the lack of termination may
cause confusion as it can be difficult to distinguish from an inactive CAN bus. If in doubt, enabling
error frame logging on the CANedge can be useful in troubleshooting.
Transmitter Bit Errors
Receiver Bit Stuffing Errors
Test #3: Setting an incorrect baud rate
In this test we configure the CANedge receiver node to have a baud rate of 493.827K vs. the baud rate of the
transmitter of 500K. This is a fairly extreme difference and results in ACK Errors for the
transmitter and Bit
Stuffing Errors for the receiver.
In more realistic scenarios, smaller differences in the baud
rate
configuration of
various nodes may cause intermittent error frames and thus message loss.
This example is rather extreme. However, in practice we have sometimes seen CAN buses that use standard
bit rates
(250K, 500K, …), but with specific bit timing settings that differ from the ones that are typically
recommended
(and hence used by the CANedge). This will not lead to a complete shut-down of the communication, but
rather
periodic frame loss of a few percentages. To resolve this, you can construct an ‘advanced bit rate’ in
the
CANedge configuration, essentially setting up the bit-timing to better match the CAN bus you’re logging
from.
Transmitter ACK Error
Receiver Bit Stuffing Errors
Test #4: Removing the acknowledging CAN node
In this test, we use three CANedge units configured as follows:
-
CANedge1: Configured to
acknowledge data -
CANedge2 A:
Configured in ‘silent mode’ (no acknowledgement) -
CANedge2 B:
Configured to transmit a CAN frame every 500 ms
In the default setup, data is transmitted by the CANedge2 B onto the CAN bus and recorded with no errors.
However, if we remove the CANedge1 from the bus there are no longer any CAN nodes to acknowledge the frames
sent by the transmitter.
As a result, the transmitter detects ACK Errors. In response, it increases its
Transmit Error Counter and raises Active Error Flags onto the CAN bus. These are in turn
recorded by CANedge2 A (which silently monitors the bus) as Form Errors.
This is due to the fact that the transmitter raises them upon identifying the lack of a dominant
bit in the ACK slot. As soon as a dominant bit is observed by the receiver in the subsequent EOF field
(which should be recessive), a Form Error is detected.
As evident, the transmitter broadcasts 16 Active Error Flags as its TEC is increased from 0 to 16 x 8 =
128.
The transmitter has now exceeded the threshold of a TEC of 127 and enters Error Passive mode. As a
result,
the transmitter still experiences ACK Errors, but now only raises Passive Error Flags (not visible to
the
receiver). At this point, the transmitter keeps attempting to transmit the same frame — and the receiver
keeps recording this retransmission sequence.
This type of error is one we often encounter in our support tickets. Specifically, users may be trying to
use our CAN loggers to record data from a single CAN node (such as a sensor-to-CAN module like our
CANmod). If they decide to enable ‘silent mode’ on the CANedge in such an installation, no CAN nodes
will acknowledge the single CAN node broadcasting data — and the result will either be empty log files,
or log files filled with retransmissions of the same CAN frame (typically at very high frequency).
Transmitter ACK Errors
Receiver Form Errors
Test #5: CAN frame collisions (no retransmission)
When setting up a CAN bus, it is key to avoid overlapping CAN IDs. Failing to do so can result in frame
collisions
as two CAN nodes may both believe they’ve won the arbitration — and hence start transmitting their frames at
the same time.
To simulate this, we use the same setup as in test #4. In addition, we connect a PCAN-USB device as a
secondary
transmitter.
The CANedge2 transmitter is now configured to output a single CAN frame every 10 ms with CAN ID 1 and a
payload of
eight 0xFF bytes. Further, we configure the CANedge2 to disable retransmission of frames that were disrupted
by
errors. The PCAN-USB outputs an identical CAN frame every 2 ms with the 1st byte of the payload changed to
0xFE. The
PCAN device has retransmissions enabled.
This setup quickly creates a frame collision, resulting in the CANedge and PCAN transmitters detecting a
Bit
Error.
In response to this, both raise an Active Error Flag, which is detected as a Bit Stuffing
Error by the
CANedge
receiver. The PCAN device immediately attempts a retransmission and succeeds, while the CANedge waits with
further
transmission until the next message is to be sent.
This type of error should of course never happen in e.g. a car, since the design and test processes will
ensure
that all CAN nodes communicate via globally unique CAN identifiers. However, this problem can easily
occur if
you install a 3rd party device (e.g. a sensor-to-CAN module) to inject data into an existing CAN bus. If
you do
not ensure the global uniqueness of the CAN IDs of external CAN nodes, you may cause frame collisions
and hence
errors on the CAN bus. This is particularly important if your external CAN node broadcasts data with
high
priority CAN IDs as you may then affect safety critical CAN nodes.
USB-to-CAN transmitter Bit Error
CANedge transmitter Bit Error
CANedge receiver Bit Stuffing Error
Test #6: CAN frame collisions (incl. retransmission)
In this test, we use the same setup as before, but we now enable retransmissions on the CANedge2 transmitter.
In this case, the frame collision results in a sequence of subsequent frame collisions as both the CANedge2
and the PCAN-USB device attempt to re-transmit their disrupted messages.
Due to the resulting Bit Errors, both raise a total of 16 Active Error Flags, which are detected as
Bit Stuffing Errors
by the silent CANedge2 receiver. Both transmitters then enter Error Passive mode and stop raising Active Error
Flags, meaning none of them can destroy CAN frames on the bus. As a result, one of the transmitters will
succeed in transmitting a full message, thus ending the retransmission frenzy — and enabling both devices to
resume transmission. However, this only lasts for a few seconds before another collision occurs.
The collision handling is a good example of how effective the CAN error handling is at ‘shutting down’
potentially
problematic sequences and enabling CAN nodes to resume communication. If a frame collision occurs, it is likely
that both CAN nodes will be set up to attempt retransmission, which would cause a jam if not for the error
handling and confinement.
USB-to-CAN transmitter Bit Errors x 16
CANedge transmitter Bit Errors x 16
CANedge receiver Bit Stuffing Errors x 16
Similar to CAN bus errors, the LIN protocol also specifies a set of four error types, which we outline briefly below.
The CANedge supports both CAN/LIN error frame logging.
As for the CAN CRC Error, this error type implies that a LIN node has calculated a different checksum vs. the one
embedded in the LIN bus frame by the transmitter. If you’re using the CANedge as a LIN Subscriber, this error
may indicate that you’ve configured the device ‘frame table’ with incorrect identifiers for some of the LIN
frames on the bus.
This can in turn be used to ‘reverse engineer’ the correct lengths and IDs of proprietary LIN frames via a
step-by-step procedure. See the CANedge Docs for details.
These occur if a specific part of the LIN message does not match the expected value, or if there is a mismatch
between what is transmitted vs. read on the LIN bus.
This error indicates an invalid synchronization field in the start of the LIN frame. It can also indicate a large
deviation between the configured bit rate for a LIN node vs. the bit rate detected from the synchronization
field.
Transmission errors can occur for LIN identifiers registered as SUBSCRIBER messages. If there are no nodes
responding to a SUBSCRIBER message, a transmission error is logged.
Example use cases for CAN error frame logging
CAN bus diagnostics in OEM prototype vehicles
An automotive OEM may have the need to record CAN error frames in the field during late stage prototype
testing. By deploying a CANedge, the OEM engineering team will both be able to troubleshoot issues based on
the actual CAN signals (speed, RPM, temperatures) — as well as issues related with the lower layer CAN
communication in their prototype systems. This is particularly vital if the issues of interest are
intermittent and e.g. only happen once or twice per month. In such scenarios, CAN bus interfaces are not
well suited — and it becomes increasingly relevant to have a cost-effective device to enable scalable
deployments for faster troubleshooting.
Remotely troubleshooting CAN errors in machinery
An OEM or aftermarket user may need to capture rare CAN error events in their machines. To do so, they deploy
a CANedge2 to record the CAN data and related error frames — and automatically upload the data via WiFi to
their own cloud server. Here, errors are automatically identified and an alert is sent to the engineering
team to immediately allow for diagnosing and resolving the issue.
FAQ
No, error frame logging is a highly specific functionality — and only relevant if you know that you need to
record this information. Typically, it’s mainly of value during diagnostics by OEM engineers — and less so for
aftermarket users. In addition, if systematic errors occur they can quickly bloat the log file size.
With the CANedge2 you can of course enable/disable error frame logging over-the-air.
Yes, the CANedge is able to record all CAN/LIN error types. It does, however, not currently record its own error
counter status as this is deemed less relevant from a logging perspective.
The CANedge is only able to raise error flags onto the CAN bus if it is configured in its ‘normal’ mode, in which
it is also able to transmit messages. If in ‘restricted’ mode it can listen to CAN frames and acknowledge CAN
frames — but not raise Active Error Flags onto the bus. In ‘monitoring’ mode (aka ‘silent mode’) it can listen
to the CAN bus traffic, but not acknowledge messages nor raise Active Error Flags.
The CANedge will always record internal CAN/LIN error frames.
If a CAN frame is erroneous, resulting in an error frame, the CANedge generally only records the error type —
without any data related to the erroneous frame (beyond the timestamp). One exception to this rule is for
acknowledgement errors, where the CANedge will still record unacknowledged CAN frames (incl. from retransmission
attempts).
Some researchers have pointed out the risk that ‘bad actors’ could utilize the CAN bus error handling
functionality to enforce remote ‘bus off’ events for safety-critical ECUs. This is a good example of why CAN bus
data loggers & interfaces like the CANedge2 with remote
over-the-air data transfer and updates need to be highly secure (see also our intro to CAN
cybersecurity). For a nice overview of a remote bus off attack, see this
intro by Adrian Colyer.
For more intros, see our guides section — or download the
‘Ultimate Guide’ PDF.
Need to log CAN bus data & errors?
Get your CAN logger today!
Recommended for you
©А. Пахомов (CTTeam, Школа Диагностики Алексея Пахомова).
В предыдущей статье мы поговорили о проблемах в шине передачи данных CAN, возникших в результате износа аккумуляторной батареи и просадки питающего напряжения при запуске ниже порога работоспособности шины. Сегодня продолжим разговор о CAN-шине, но немного в другом ключе: прежде всего вспомним принцип ее работы, а затем рассмотрим один из случаев топологии шины и разберем осциллограмму дефекта.
Эта шина используется чаще всего как средство обмена данными в системах, для которых критично быстродействие и время принятия решения. Таковыми являются, например, система управления движением, объединяющая между собой блоки управления двигателем, автоматической трансмиссией, антиблокировочной системой тормозов, усилителем руля и т.п.
Конструктивно шина представляет собой неэкранированную витую пару. Провода шины называются CAN High и CAN Low.
Шина может находиться в двух состояниях:
- Рецессивное состояние, или логическая единица. Оба провода в этой ситуации имеют практически одинаковый потенциал: и на проводе CAN High, и на проводе CAN Low присутствует около 2,5 В. В рецессивном состоянии шина может находиться сколь угодно долго, хотя в реальности этого не происходит, ведь рецессивное состояние – это всего лишь пауза между сеансами передачи информации.
- Доминантное состояние, или логический ноль. В него шина переходит тогда, когда один из входящих в сеть блоков управления начинает передачу данных. Потенциалы на проводах шины меняются следующим образом: на проводе CAN High потенциал повышается на один вольт, на проводе CAN Low наоборот, становится на один вольт ниже.
Рассмотрим форму сигнала шины, чтобы обосновать ее помехоустойчивость:
На рисунке показаны доминантный и рецессивный уровни шины, а также воздействие на шину электромагнитной помехи. Особенностью обработки сигналов шины является то, что в расчет берется не сам уровень сигнала, а разница уровней между проводами CAN High и CAN Low. При рецессивном уровне эта разница близка к нулю, при доминантном уровне она максимальна.
В витой паре провода располагаются очень близко друг к другу. Если возникает внешняя электромагнитная помеха X, то она является синфазной и наводит одинаковый всплеск напряжения в обоих проводах шины. В итоге на обоих проводах появляется наведенный помехой импульс, но разница потенциалов между проводами при этом не меняется. Это позволяет эффективно подавлять внешние помехи, что является большим преимуществом CAN-шины.
На самом деле витая пара – давно известный способ борьбы с помехами. В медицине, например, в кардиостимуляторах, где требуется высочайшая помехоустойчивость, она применяется очень широко.
Сигнал шины поступает в блок управления на дифференциальный усилитель и обрабатывается. Иллюстрация поясняет процесс обработки:
Большинство автопроизводителей придерживаются скорости передачи 500 кБд, соответственно, продолжительность одного бита при этом составит 2 мкс.
Поговорим о топологии CAN-шины. Физически у шины нет начала и нет конца, шина – это просто единая сеть. Чаще всего встречаются два типа топологии: линейная топология и топология «пассивная звезда», а также их сочетания.
На современных автомобилях шина CAN очень разветвленная. Чтобы не перегружать линию большим количеством передаваемых данных, шина может состоять из нескольких ветвей, объединенных межсетевым шлюзом, иначе называемым Gateway. В итоге сеть представляет собой несколько ответвлений, в том числе и на диагностический разъем, использующих разную скорость и протоколы обмена.
Поэтому топология шины – вопрос для диагноста очень актуальный и, к сожалению, довольно сложный. Из тех электрических схем, которыми располагает диагност, не всегда можно понять топологию. Но в документации некоторых автопроизводителей приводится полная и подробная информация, в этом случае задача сильно упрощается.
Не зная тонкостей организации шины, найти в ней неисправность бывает достаточно сложно. Например, при наличии окисления контактов в разъеме пропадает связь с целым рядом блоков управления. Наличие под рукой топологии шины позволяет легко находить подобные проблемы, а отсутствие приводит к большой потере времени.
Ну что ж, мы немного освежили в памяти теорию шины, теперь самое время перейти к практике.
Перед нами автомобиль Infinitit Q50, оснащенный весьма редким турбированным мотором VR30DDT объемом 3.0 л и мощностью 400 лошадиных сил. Но проблема заключается не в этом замечательном агрегате, а как раз в CAN-шине: подключив диагностический сканер, не удается установить связь с доброй половиной блоков управления.
Нам повезло – Nissan относится к тому узкому кругу производителей, которые дают диагностам качественную и полноценную информацию. В том числе есть в документации и подробная топология бортовой шины обмена данными. Открываем, смотрим:
Следует сказать, что приведенная блок-схема достаточно общая. В документации имеется гораздо более подробная электрическая схема со всеми проводами и номерами контактов в блоках, но сейчас она нам пока что ни к чему, нам важно понять общую топологию.
Итак, первое, что нужно увидеть, это то, что вся сеть разделена на три большие ветви, обведенные пунктиром:
- CAN communication circuit 1 (Коммуникационная цепь CAN 1);
- CAN communication circuit 2 (Коммуникационная цепь CAN 2);
- Chassis communication circuit (Коммуникационная цепь шасси).
Первые две цепи связаны между собой посредством CAN gateway (найдите его на иллюстрации). Цепь шасси связана с цепью CAN 2 через блок управления шасси, который также играет роль своеобразного Gateway.
А теперь вновь обратимся к сканеру и посмотрим, какие из блоков управления не выходят на связь. Дилерский сканер предоставляет нам очень удобную функцию: на экран выводятся блоки каждой из цепей по отдельности, а цветом отображается возможность (зеленый) либо невозможность (красный) установить с ними связь. Вот блоки цепи CAN 1:
А это – блоки цепи CAN 2. Как видно, связи с ними попросту нет:
Также нет связи с блоками цепи шасси, но это и понятно: эта цепь, согласно блок-схеме, подключена к цепи CAN 2.
Ну что ж, задача почти решена, осталось лишь локализовать неисправность. А для этого воспользуемся мотортестером и снимем осциллограмму на проводах шины сначала в CAN 1, а затем в CAN 2 и сравним их.
Сделать это очень несложно, ведь обе шины выведены прямо на диагностический разъем. Согласно более подробной схеме, о которой упоминалось выше, на контакты диагностической колодки 6 и 14 выведены провода CAN 1, а на контакты 12 и 13 – провода CAN 2.
Снимаем осциллограмму в цепи CAN 1. Она имеет прямо-таки академический вид:
Давайте обмерим ее с помощью линеек.
- На проводе CAN High в рецессивном состоянии потенциал составил 2,26 В, на проводе CAN Low – 2,25 В.
- На проводе CAN High в доминантном состоянии потенциал составил 3,58 В, на проводе CAN Low – 1,41 В.
- Ширина импульса, соответствующего одной единице передаваемой информации, составляет 2 мкс (обведено красным прямоугольником).
Просто идеальное соответствие теории и практики. Конечно, полосы пропускания нашего прибора явно недостаточно для корректного отображения сигнала, слишком уж широк его спектр. Однако, если закрыть на это глаза, то вполне можно оценить качество сигнала и сделать необходимые выводы.
А теперь делаем ту же операцию на контактах диагностической колодки 12 и 13, чтобы получить осциллограмму сигнала CAN 2. Вот она:
Для наглядности масштаб осциллограмм на обеих иллюстрациях один и тот же.
То, что вы видите на этой осциллограмме, называется «мусор». Часто диагносты так и говорят: блок мусорит в шину. Вот только как найти блок, который это делает? Методика здесь очень проста и сводится она к поочередному отключению блоков и повторному наблюдению за сигналом шины.
Где именно находится тот или иной блок на автомобиле, в документации, как правило, показано. Например, на этом «финике» блоки расположены так:
Но в нашем случае все проще. Кстати, маленький лайфхак, возьмите на заметку. В автомобилях Nissan и Infiniti чаще всего причиной наличия мусора в CAN-шине является блок ABS. Сняв разъем с блока, сразу получаем нормальный обмен и связь сканера со всеми блоками ветви CAN 2:
Обратите внимание на то, что связь в цепи CAN 2 есть со всеми блоками, кроме блока ABS, ведь он отключен.
Завершая разговор, хотелось бы обратить ваше внимание еще на один важный нюанс. Частота следования импульсов по CAN-шине составляет 500 кГц. Поэтому при получении осциллограммы необходимо задействовать максимально возможную частоту дискретизации мотортестера, на какую только он способен.
Если частоту дискретизации вы зададите низкую, то импульсы на осциллограмме будут сильно искажены. В качестве примера посмотрите, как выглядит осциллограмма сигнала CAN-шины при специально сниженной частоте дискретизации прибора:
Красным прямоугольником обведено время, в которое укладывается одно деление сетки. Оно составляет 0,2 мс. А на осциллограмме, которую мы рассматривали ранее, это время было равно 5 мкс, поэтому отображение импульсов было более правильным. Имейте это ввиду и не допускайте ошибок!
Всем привет!
Спешу поделиться радостным для меня событием, а именно победой над надоедливой ошибкой по каншине!
В предыдущих двух записях (тут и тут) я уже описывал свой путь по борьбе с данной ошибкой. Забегая вперед, скажу, что все могло обойтись для меня дешевле, однако в силу свой лени, пришлось заплатить деньги специально обученному человеку ))
Ну по порядку:
Значится после проверки скруток в ногах водителя было установлено, что в указанном месте все отремонтировано до меня.
Скрутки, расположенные в левой средней стойке, были отремонтированы мною, однако ошибка не ушла.
Исходя из записи камрада JendoZzz1982 следовало, что под обшивкой правой средней стойки на рестайловом Туареге имеется еще 5 скруток, 4 из которых по каншине. Для того, чтобы до них добраться, необходимо снимать пассажирское сидение. Без его снятия добраться не получится — проверял )
Кроме того, исходя из записи камрада Nill следовало, что проблема может быть не только в проводке, но и в микросхемах каншины, расположенных непосредственно в блоках.
Не знаю почему, видимо от нежелания ковыряться со снятием пассажирского кресла, я решил, что скрутки в правой средней стойке у меня целы, и искать необходимо по блокам. Для этих целей необходим был чудо прибор, именуемый осциллографом. Ни знаний, ни умений по пользованию последним, как собственно и самого прибора у меня не было, и мною был найден электрик, обладающий всеми необходимыми познаниями и оборудованием.
Итак, машина была загнана к электрику и началась работа по поиску. В итоге были разобраны двери, панель приборов и т.д.
По результатам работ было установлено, что ошибка связана с центральным блоком комфорта и блоком управления пассажирским сидением. При разборе соответствующих блоков были видны имеющиеся окислы, однако не связанные с каншиной. По внешнему виду микросхемы были в порядке.
Кстати, вдруг кому нужно будет, микросхемы по каншине имеют следующую маркировку:
Уже на данном этапе я стал понимать, что проблема не в блоках, а именно в скрутках, расположенных под обшивкой правой средней стойки.
Мой вывод был основан во-первых, на расположении блоков, с которыми была связана ошибка (напомню это центральный блок комфорта и блок управления передним пассажирским сидением), и во-вторых, из анализа аналогичных тем, проблема с блоком была установлена лишь у камрада Nill, что могло говорить о меньшей вероятности такого рода проблемы, а тут выходило, что микросхемы кончились сразу в двух блоках, во что верилось с трудом.
Я сообщил о своих догадках электрику и предложил ему прежде, чем заказывать и менять микросхемы, проверить скрутки. Он согласился со мной, но все же стоял на том, что исходя из показаний осциллографа и диагностики, проблема вероятнее всего все же именно в блоках. Спорить я не стал, но остался при своем мнении ))
Итак, после проверки скруток в правой средней стойке, информация камарада JendoZzz1982 подтверждена. Там действительно находится 5 сркуток, 4 из которых относятся к каншине. И вот одна из скруток развалиась в руках ))) на фото развалившаяся скрутка обведена желтым!
5 скруток, расположенных в правой средней стойке
Рассыпавшаяся скрутка обведена желтым
Рассыпавшаяся скрутка обведена желтым
Остальные скрутки были в порядке, однако для верности, они также были отремонтированы. Отремонтированные скрутки пропаяны и помещены в термоусадку.
При проверке, ошибка по каншине не обнаружена! УРА, УРА, УРА!
Итак, по завершению записи, хотелось бы отметить, что на рестайловом Туареге скрутки расположены под обшивками левой и правой центральных стоек. Проверять необходимо и там, и там — у меня скрутки сгнили с обеих сторон (по одной скрутке с каждой стороны).
Итого: за работу электрика я отдал 7500 р.
Всем удачи!
В предыдущей статье мы поговорили о проблемах в шине передачи данных CAN, возникших в результате износа аккумуляторной батареи и просадки питающего напряжения при запуске ниже порога работоспособности шины. Сегодня продолжим разговор о CAN-шине, но немного в другом ключе: прежде всего вспомним принцип ее работы, а затем рассмотрим один из случаев топологии шины и разберем осциллограмму дефекта.
Эта шина используется чаще всего как средство обмена данными в системах, для которых критично быстродействие и время принятия решения. Таковыми являются, например, система управления движением, объединяющая между собой блоки управления двигателем, автоматической трансмиссией, антиблокировочной системой тормозов, усилителем руля и т.п.
Конструктивно шина представляет собой неэкранированную витую пару. Провода шины называются CAN High и CAN Low.
Шина может находиться в двух состояниях:
- Рецессивное состояние, или логическая единица. Оба провода в этой ситуации имеют практически одинаковый потенциал: и на проводе CAN High, и на проводе CAN Low присутствует около 2 , 5 В. В рецессивном состоянии шина может находиться сколь угодно долго, хотя в реальности этого не происходит, ведь рецессивное состояние – это всего лишь пауза между сеансами передачи информации.
- Доминантное состояние, или логический ноль. В него шина переходит тогда, когда один из входящих в сеть блоков управления начинает передачу данных. Потенциалы на проводах шины меняются следующим образом: на проводе CAN High потенциал повышается на один вольт, на проводе CAN Low наоборот, становится на один вольт ниже.
Рассмотрим форму сигнала шины, чтобы обосновать ее помехоустойчивость:
На рисунке показаны доминантный и рецессивный уровни шины, а также воздействие на шину электромагнитной помехи. Особенностью обработки сигналов шины является то, что в расчет берется не сам уровень сигнала, а разница уровней между проводами CAN High и CAN Low. При рецессивном уровне эта разница близка к нулю, при доминантном уровне она максимальна.
В витой паре провода располагаются очень близко друг к другу. Если возникает внешняя электромагнитная помеха X, то она является синфазной и наводит одинаковый всплеск напряжения в обоих проводах шины. В итоге на обоих проводах появляется наведенный помехой импульс, но разница потенциалов между проводами при этом не меняется. Это позволяет эффективно подавлять внешние помехи, что является большим преимуществом CAN-шины.
На самом деле витая пара – давно известный способ борьбы с помехами. В медицине, например, в кардиостимуляторах, где требуется высочайшая помехоустойчивость, она применяется очень широко.
Сигнал шины поступает в блок управления на дифференциальный усилитель и обрабатывается. Иллюстрация поясняет процесс обработки:
Большинство автопроизводителей придерживаются скорости передачи 500 кБд, соответственно, продолжительность одного бита при этом составит 2 мкс.
Поговорим о топологии CAN-шины. Физически у шины нет начала и нет конца, шина – это просто единая сеть. Чаще всего встречаются два типа топологии: линейная топология и топология «пассивная звезда», а также их сочетания.
На современных автомобилях шина CAN очень разветвленная. Чтобы не перегружать линию большим количеством передаваемых данных, шина может состоять из нескольких ветвей, объединенных межсетевым шлюзом, иначе называемым Gateway. В итоге сеть представляет собой несколько ответвлений, в том числе и на диагностический разъем, использующих разную скорость и протоколы обмена.
Поэтому топология шины – вопрос для диагноста очень актуальный и, к сожалению, довольно сложный. Из тех электрических схем, которыми располагает диагност, не всегда можно понять топологию. Но в документации некоторых автопроизводителей приводится полная и подробная информация, в этом случае задача сильно упрощается.
Не зная тонкостей организации шины, найти в ней неисправность бывает достаточно сложно. Например, при наличии окисления контактов в разъеме пропадает связь с целым рядом блоков управления. Наличие под рукой топологии шины позволяет легко находить подобные проблемы, а отсутствие приводит к большой потере времени.
Ну что ж, мы немного освежили в памяти теорию шины, теперь самое время перейти к практике.
Перед нами автомобиль Infinitit Q 50 , оснащенный весьма редким турбированным мотором VR 30 DDT объемом 3 . 0 л и мощностью 400 лошадиных сил. Но проблема заключается не в этом замечательном агрегате, а как раз в CAN-шине: подключив диагностический сканер, не удается установить связь с доброй половиной блоков управления.
Нам повезло – Nissan относится к тому узкому кругу производителей, которые дают диагностам качественную и полноценную информацию. В том числе есть в документации и подробная топология бортовой шины обмена данными. Открываем, смотрим:
Следует сказать, что приведенная блок-схема достаточно общая. В документации имеется гораздо более подробная электрическая схема со всеми проводами и номерами контактов в блоках, но сейчас она нам пока что ни к чему, нам важно понять общую топологию.
Итак, первое, что нужно увидеть, это то, что вся сеть разделена на три большие ветви, обведенные пунктиром:
- CAN communication circuit 1 (Коммуникационная цепь CAN 1 );
- CAN communication circuit 2 (Коммуникационная цепь CAN 2 );
- Chassis communication circuit (Коммуникационная цепь шасси).
Первые две цепи связаны между собой посредством CAN gateway (найдите его на иллюстрации). Цепь шасси связана с цепью CAN 2 через блок управления шасси, который также играет роль своеобразного Gateway.
А теперь вновь обратимся к сканеру и посмотрим, какие из блоков управления не выходят на связь. Дилерский сканер предоставляет нам очень удобную функцию: на экран выводятся блоки каждой из цепей по отдельности, а цветом отображается возможность (зеленый) либо невозможность (красный) установить с ними связь. Вот блоки цепи CAN 1 :
А это – блоки цепи CAN 2 . Как видно, связи с ними попросту нет:
Также нет связи с блоками цепи шасси, но это и понятно: эта цепь, согласно блок-схеме, подключена к цепи CAN 2 .
Ну что ж, задача почти решена, осталось лишь локализовать неисправность. А для этого воспользуемся мотортестером и снимем осциллограмму на проводах шины сначала в CAN 1 , а затем в CAN 2 и сравним их.
Сделать это очень несложно, ведь обе шины выведены прямо на диагностический разъем. Согласно более подробной схеме, о которой упоминалось выше, на контакты диагностической колодки 6 и 14 выведены провода CAN 1 , а на контакты 12 и 13 – провода CAN 2 .
Снимаем осциллограмму в цепи CAN 1 . Она имеет прямо-таки академический вид:
Давайте обмерим ее с помощью линеек.
- На проводе CAN High в рецессивном состоянии потенциал составил 2 , 26 В, на проводе CAN Low – 2 , 25 В.
- На проводе CAN High в доминантном состоянии потенциал составил 3 , 58 В, на проводе CAN Low – 1 , 41 В.
- Ширина импульса, соответствующего одной единице передаваемой информации, составляет 2 мкс (обведено красным прямоугольником).
Просто идеальное соответствие теории и практики. Конечно, полосы пропускания нашего прибора явно недостаточно для корректного отображения сигнала, слишком уж широк его спектр. Однако, если закрыть на это глаза, то вполне можно оценить качество сигнала и сделать необходимые выводы.
А теперь делаем ту же операцию на контактах диагностической колодки 12 и 13 , чтобы получить осциллограмму сигнала CAN 2 . Вот она:
Для наглядности масштаб осциллограмм на обеих иллюстрациях один и тот же.
То, что вы видите на этой осциллограмме, называется «мусор». Часто диагносты так и говорят: блок мусорит в шину. Вот только как найти блок, который это делает? Методика здесь очень проста и сводится она к поочередному отключению блоков и повторному наблюдению за сигналом шины.
Где именно находится тот или иной блок на автомобиле, в документации, как правило, показано. Например, на этом «финике» блоки расположены так:
Но в нашем случае все проще. Кстати, маленький лайфхак, возьмите на заметку. В автомобилях Nissan и Infiniti чаще всего причиной наличия мусора в CAN-шине является блок ABS. Сняв разъем с блока, сразу получаем нормальный обмен и связь сканера со всеми блоками ветви CAN 2 :
Обратите внимание на то, что связь в цепи CAN 2 есть со всеми блоками, кроме блока ABS, ведь он отключен.
Завершая разговор, хотелось бы обратить ваше внимание еще на один важный нюанс. Частота следования импульсов по CAN-шине составляет 500 кГц. Поэтому при получении осциллограммы необходимо задействовать максимально возможную частоту дискретизации мотортестера, на какую только он способен.
Если частоту дискретизации вы зададите низкую, то импульсы на осциллограмме будут сильно искажены. В качестве примера посмотрите, как выглядит осциллограмма сигнала CAN-шины при специально сниженной частоте дискретизации прибора:
Красным прямоугольником обведено время, в которое укладывается одно деление сетки. Оно составляет 0 , 2 мс. А на осциллограмме, которую мы рассматривали ранее, это время было равно 5 мкс, поэтому отображение импульсов было более правильным. Имейте это ввиду и не допускайте ошибок!
Источник
Протокол CAN. Описание, формат кадра, контроль ошибок.
Приветствую всех на нашем сайте! Сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…
CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.
Основные характеристики протокола CAN:
- очень высокая надежность и защищенность
- каждое сообщение имеет свой собственный приоритет
- реализован механизм обнаружения ошибок
- автоматическая повторная отправка сообщений, которые были доставлены с ошибкой
- уже упомянутый широковещательный характер передачи данных
- возможность присутствия нескольких ведущих (master) устройств в одной сети
- широкий диапазон скоростей работы
- высокая устойчивость интерфейса к помехам
- кроме того, есть механизм обнаружения «сбойных» узлов с последующим удалением таких узлов из сети.
Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь! С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».
Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна 🙂 Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:
| Скорость | Длина линии |
|---|---|
| 1 Мбит/с | 50 м |
| 500 кбит/с | 100 м |
| 125 кбит/с | 500 м |
| 10 кбит/с | 5 км |
Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:
В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.
Важнейшим свойством является то, что если один из узлов сети хочет выставить на линии рецессивный бит, а другой доминантный, то в итоге на линии окажется доминантный бит. В общем-то отсюда и следует его название, от слова «доминировать» 🙂 Очень хорошо этот процесс иллюстрирует пример с оптоволоконной линией. Как вы помните, в оптоволокне для передачи данных используется «свет», либо он есть (единица), либо его нет (ноль). При использовании в CAN-сети «свет» — доминантный бит, соответственно, отсутствие света или «темнота» — рецессивный. Вспоминаем про важнейшее свойство передачи данных в сети…
Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети!
При использовании электрического сигнала устройство, желающее передать в линию доминантный бит, может подтянуть линию к земле. Это и приведет к тому, что на линии будет доминантный бит независимо от того, что выдают на линию другие участники коммуникации.
Это свойство используется для арбитража в сети CAN. Пусть несколько устройств хотят передать данные. Каждый из этих передатчиков сравнивает значение, которое он передает, со значением, фактически присутствующим на линии. В том случае, если передаваемое значение совпадает со считанным, устройство продолжает высылать свои данные. Если значения совпали у нескольких устройств, то все они продолжают передачу как ни в чем не бывало.
Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде 🙂
Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).
С этим вроде бы разобрались, давайте двигаться дальше!
Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:
- Кадр данных (data frame)
- Кадр удаленного запроса (remote frame)
- Кадр перегрузки (overload frame)
- Кадр ошибки (error frame)
Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:
| Поле | Длина | Описание |
|---|---|---|
| Начало кадра (SOF) | 1 бит | Начало передачи кадра |
| Идентификатор (ID) | 11 бит | Идентификатор сообщения |
| Запрос на передачу (RTR) | 1 бит | Доминантный бит |
| Бит расширения идентификатора (IDE) | 1 бит | Бит определяет длину идентификатора, для базового формата — доминантный бит |
| Зарезервированный бит | 1 бит | Зарезервировано |
| Длина данных (DLC) | 4 бита | Количество байт данных |
| Данные | 0 — 8 байт | Данные |
| Контрольная сумма (CRC) | 15 бит | Контрольная сумма |
| Разграничитель контрольной суммы | 1 бит | Рецессивный бит |
| Промежуток подтверждения (ACK) | 1 бит | Для приемника — доминантный бит, для передатчика — рецессивный |
| Разграничитель подтверждения | 1 бит | Рецессивный бит |
| Конец кадра (EOF) | 7 бит | Все биты рецессивные |
А это структура расширенного:
| Поле | Длина | Описание |
|---|---|---|
| Начало кадра (SOF) | 1 бит | Начало передачи кадра |
| Идентификатор A (ID A) | 11 бит | Первая часть идентификатора |
| Подмена запроса на передачу (SRR) | 1 бит | Рецессивный бит |
| Бит расширения идентификатора (IDE) | 1 бит | Бит определяет длину идентификатора, для расширенного формата — рецессивный бит |
| Идентификатор B (ID B) | 18 бит | Вторая часть идентификатора |
| Запрос на передачу (RTR) | 1 бит | Доминантный бит |
| Зарезервированные биты | 2 бита | Зарезервировано |
| Длина данных (DLC) | 4 бита | Количество байт данных |
| Данные | 0 — 8 байт | Данные |
| Контрольная сумма (CRC) | 15 бит | Контрольная сумма |
| Разграничитель контрольной суммы | 1 бит | Рецессивный бит |
| Промежуток подтверждения (ACK) | 1 бит | Для приемника — доминантный бит, для передатчика — рецессивный |
| Разграничитель подтверждения | 1 бит | Рецессивный бит |
| Конец кадра (EOF) | 7 бит | Все биты рецессивные |
Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.
Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.
Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.
Кадр перегрузки (overload frame) используется очень редко… Его идея и назначение заключается в том, что с его помощью устройство, которое в данный момент не может принять данные, запрашивает повторную передачу этих же данных.
А давайте вернемся чуть назад, к арбитражу данных, и рассмотрим, что это может означать на практике! Итак, несколько устройств начинают передачу сообщения, а точнее кадра данных. Передается бит начала кадра и затем начинается передача идентификатора сообщения. Как вы помните, приоритет будет у того устройства, которое будет передавать доминантный бит, в тот момент, когда все остальные будут передавать рецессивный. То есть чем «позже» среди битов идентификатора появится «рецессивный бит», тем выше будет его приоритет! Другими словами: более высокий приоритет при использовании интерфейса CAN имеют сообщения с меньшим значением идентификатора.
Первые два типа кадров — кадр данных и кадр удаленного запроса — отделяются от других кадров специальным межкадровым промежутком (паузой). А для фреймов ошибки и перегрузки предусмотрена передача без пауз, чтобы обеспечить их скорейшую обработку узлами сети.
Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN! Стандарт предусматривает несколько механизмов контроля ошибок.
- Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
- Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
- Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
- Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.
Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 🙂
Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.
И на этом еще не все! Каждый узел может находиться в одном из трех состояний:
- Error Active
- Error Passive
- Bus Off
Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:
- Счетчик ошибок передачи
- Счетчик ошибок приема
Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.
Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.
Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:
- Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
- Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
- И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, никакие другие.
Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании 🙂
И на этой позитивной ноте на сегодня заканчиваем, скоро займемся практической реализацией протокола, также поговорим о микросхемах и устройствах, обеспечивающих работу с CAN. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте!
Источник
Controller Area Network
(шина данных CAN)
Или разговорно: «Шина CAN».
В период с 1984 по 1986 г.г., компанией Robert Bosch GmbH был придуман, разработан и воплощен в производство стандарт CAN — Controller Area Network (сеть контроллеров), основной целью которого является объединение в единую сеть различных исполнительных устройств, датчиков, сенсоров и т.п.
И как оказалось впоследствии, шина данных CAN действительно имела множество преимуществ перед обычными жгутами проводов, причислим некоторые:
Электромагнитная совместимость
Раньше об этом понятии задумывались мало или вообще не задумывались. Потому что автомобилям хватало небольшого пучка проводов и пару-тройку устройств для нормальной работы двигателя внутреннего сгорания.
Однако технический прогресс идет вперед, вопросы экологии, безопасности дорожного движения и водителя, как участника этого движения, выходят на первое место, что приводит к постоянному увеличению количества электронных устройств на автомобиле.
Что такое «Электромагнитная совместимость на автомобиле»?
Это способность одновременного и стабильного функционирования множества различных электронных устройств на автомобиле без создания электромагнитных помех друг другу.
Шина CAN как раз отвечает этим важным требованиям.
Более конкретно об этом вопросе чуть позже.
Уменьшение количества кабельных соединений
Сначала немного о том, что же такое эта шина и как она выглядит:
Шина данных CAN – это обычная «витая пара», вот как на фото справа. Это специально скрученный двухжильный провод.
К этой витой паре подключены различные блоки управления – их называют «пользователи». Передача данных идет одновременно по двум проводам этой «витой пары». Важно знать, что логические уровни шины имеют зеркальное отображение: если по одному проводу передается уровень логического «нуля», то по другому проводу одновременно передается уровень логической «единицы».
Почему используется двухпроводная схема передачи данных:
- для стабильности распознавания ошибок
- для увеличения и повышения надёжности работы по передаче данных
Предположим, что пик напряжения возникнет только на одном проводе (например, вследствии проблем по электромагнитной совместимости).
И тогда блоки-приёмники могут идентифицировать это как ошибку и проигнорировать данный пик напряжения.
Если же произойдет короткое замыкание или обрыв одного из двух проводов, то благодаря интегрированной программно-аппаратной концепции надёжности произойдёт переключение в режим работы по однопроводной схеме, и повреждённая передающая линия использоваться не будет.
Так вот, продолжим о «уменьшении количества соединений между устройствами шины CAN»:
- Провода от датчиков проводятся только к ближайшему блоку управления, который преобразует измеренные значения в пакет данных и передаёт его на шину данных CAN.
- Уменьшение количества штекерных соединений
- Уменьшение количества контактных выводов на блоках управления
- Сигналами с одного датчика (например, с датчика температуры охлаждающей жидкости) могут воспользоваться различные системы
Пакет данных шины CAN
А сейчас давайте посмотрим, что представляет из себя «пакет данных» шины CAN. Он состоит из семи последовательных полей (отрезков).
На приведенном внизу рисунке показано восемь полей, последнее Intermission– «Пауза между пакетами данных» и оно не входит в Data Frame:
Цифры в каждом поле показывают количество битов, используемых в каждом сообщении (пакете данных).
Описание полей пакета данных<
Start of Frame
Маркирует начало сообщения (стартов, бит) и синхронизирует все модули шины.
Arbitration Field
Это поле состоит из идентификатора адреса в 11 бит и 1 контрольного бита и запрос (Remote Transmission Request-Bit).
Этот контрольный бит маркирует пакет как Data Frame (фрейм сообщения) или как Remote Frame (фрейм запроса) без байтов данных.
Control Field (управл. биты)
Поле управления (6 бит) содержит бит IDE (Identifier Extension Bit) для распознавания стандартного и расширенного формата, резервный бит для последующих расширений и — в последних 4 битах — количество байтов данных, заложенных в Data Field (поле данных).
Data Field (данные)
Поле данных может содержать от 0 до 8 байт данных. Сообщение по шине данных CAN длиной 0 байт используется для синхронизации распределённых процессов
CRC Field (контрольное поле)
Поле CRC (Cyclic-Redundancy-Check Field) содержит 16 бит и служит для контрольного распознавания ошибок при передаче данных.
АСК Field (подтверждение приема)
Поле АСК (Acknowledgement Field) содержит сигнал квитирования всех блоков-приёмников, получивших сообщение по шине данных CAN без ошибок (квитирование — подтверждение приема, отправка квитанции — управляющее сообщение или сигнал, выдаваемые в ответ на принятое сообщение).
End of Frame (конец фрейма)
Маркирует конец пакета данных
Intermission (интервал)
Интервал между двумя пакетами данных. Интервал должен составлять не менее 3 битов. После этого любой блок управления может передавать следующий пакет данных.
IDLE (режим покоя)
Если ни один блок управления не передаёт сообщений, то шина данных CAN остается в режиме покоя до передачи следующего пакета данных.
Прием и передача данных
Шина данных CAN является двунаправленной шиной — любой из подключённых блоков может, как передавать, так и принимать сообщения.
На приведенном выше рисунке слово Dashboard можно заменить на привычное (разговорное и чаще применяемое) «Шлюз».
К примеру на некоторых автомобилях, шлюзом между быстрой и медленной шиной является панель приборов (Ауди,Фольксваген), у Мерседеса функции шлюза выполняет EZS (замок зажигания), хотя сама панель работает в двух сетях, для отображения как салонной, так и моторной информации.
На следующих поколениях автомобилей с 2002 года начали использовать отдельный блок ZGW (центральный интерфейс), который выполняет функции шлюза, хранит кодировки комплектации авто и через него работает диагностика по CAN шине (именно по «чистому» CAN – без к-линий).
Шины данных CAN существуют с различными скоростями передачи данных и их иногда называют «быстрая шина» (High-Speed-CAN) и «медленная шина» (Low- Speed-CAN).
Например, High-Speed-CAN – это шина двигателя, АКПП и т.п., имеет скорость передачи данных 500 Кбит
Low-Speed-CAN — это шины для управления стеклоподъемниками, кондиционером и т.п. , со скоростью передачи данных 100 Кбит.
Порядок и формат передачи и приёма сообщений пользователями определён в протоколе обмена данных.
Существенным отличительным признакомшины данных CAN по сравнению с другими шинными системами, базирующимися на принципе абонентской адресации, является соотнесённая с сообщением адресация.
- каждому сообщению по шине данных CAN присваивается его постоянный адрес (идентификатор), маркирующий содержание этого сообщения (например: температура охлаждающей жидкости).
- протокол шины данных CAN допускает передачу до 2048 различных сообщений, причём адреса с 2033 по 2048 являются постоянно закреплёнными. Объём данных одного сообщения по шине данных CAN составляет 8 байт.
Блок-приёмник обрабатывает только те сообщения(пакеты данных), которые сохранены в его списке принимаемых по шине данных CAN сообщений (контроль назначения сообщения).
Пакеты данных могут передаваться только в том случае, если шина данных CAN свободна (то есть, если после передачи последнего пакета данных последовал интервал в 3 бита, и никакой из блоков управления не начинает передавать сообщение). При этом логический уровень шины данных является рецессивным (логическая «1»)
Шина данных CAN: РАСШИРЕННЫЕ ВОЗМОЖНОСТИ проведения Диагностики
Так как сигналы с одного датчика (например, датчика температуры, датчика скорости и др.), может использоваться различными системами, то в том случае, если наличие неисправности отображают все использующие данный сигнал системы, неисправным является, как правило, датчик или блок управления, обрабатывающий его сигналы.
Если же сообщение о неисправности поступает только от одной системы, хотя данный сигнал используется и другими системами, то причина неисправности, в большинстве случаев, заключается в обрабатывающем этот сигнал блоке управления или сервомеханизме
Высокий уровень защиты передаваемых данных
Высокий уровень защиты передаваемых данных беспечивается даже при сильных помехах.
При этом обеспечивается высокая скорость передачи данных (до 1 Mbit/s)
За счет чего это достигается:
- Механизм обнаружения ошибок Механизм исправления ошибок
- Сохранение работоспособности при высоком уровне электромагнитных помех
- Распределение приоритетов команд
- Работа в реальном режиме времени
Распознавание ошибок
Помехи при передаче данных могут приводить к возникновению ошибок. Такие ошибки при передаче данных надо распознавать и устранять. Протокол шины данных CAN различает два уровня распознавания ошибок:
- механизмы на уровне Data Frame (фрейм сообщения)
- механизмы на уровне битов
Cyclic-Redundancy-Check:
на основе передаваемого по шине данных CAN сообщения модуль-передатчик рассчитывает контрольные биты, которые передаются вместе с пакетом данных в поле «CRC Field». Модуль-приёмник заново вычисляет эти контрольные биты на основе принятого по шине данных CAN сообщения и сравнивает их с контрольными битами, полученными вместе с этим сообщением.
Frame Check:
Этот механизм проверяет структуру передаваемого фрейма, то есть перепроверяются битовые поля с заданным фиксированным форматом и длина фрейма.
Распознанные функцией Frame Check ошибки обозначаются как ошибки формата.
Механизмы на уровне битов
Мониторинг
Каждый модуль при передаче сообщения отслеживает логический уровень шины данных CAN и на основе этого распознаёт различия между переданным и принятым битом. Благодаря этому обеспечивается надёжное распознавание глобальных и возникающих в блоке-передатчике локальных ошибок по битам.
Bit Stuffing:
В каждом пакете данных между полем «Start of Frame» и концом поля «CRC Field» должно быть не более 5 последовательных битов с одинаковой полярностью. После каждой последовательности из 5 одинаковых битов блок-передатчик добавляет в поток битов один бит с противоположной полярностью. Блоки- приёмники, в свою очередь, удаляют эти биты после приёма сообщения по шине данных CAN.
Механизм устранения ошибок
Если какой-либо модуль шины данных CAN распознаёт ошибку, то он прерывает текущий процесс передачи данных, отправляя сообщение об ошибке. Сообщение об ошибке состоит из 6 доминантных битов.
Благодаря этому сообщению об ошибке все подключённые к шине данных CAN блоки управления оповещаются о возникшей локальной ошибке и, соответственно, игнорируют переданное сообщение.
После короткой паузы все блоки управления снова смогут передавать сообщения по шине данных CAN, причём первым опять будет отправлено сообщение с наивысшим приоритетом (мотор, АКПП и т.п.).
Блок управления, чьё сообщение по шине данных CAN обусловило возникновение ошибки, также начинает повторную передачу своего сообщения (Automatic Repeat Request — автоматический повтор запроса).
ПРИОРИТЕТЫ шины данных CAN
«ПРИНЦИП ПРИОРИТЕТНОСТИ»
Если несколько блоков управления одновременно начинают передавать сообщения, то вступает в силу «принцип приоритетности», согласно которому сообщение по шине данных CAN с наивысшим приоритетом будет передаваться первымбез потери времени или битов (арбитраж доступа к шине данных).
Каждый блок управления, утрачивающий право арбитража, автоматически переключается на приём и повторяет свою попытку отправить сообщение только после того, как шина данных CAN снова освободится.
Кроме пакетов данных существует также пакет запроса определённого сообщения по шине данных CAN. В этом случае блок управления, который может предоставить запрашиваемый пакет данных, реагирует на изданный запрос.
Для обработки данных в режиме реального времени должна быть обеспечена возможность их быстрой передачи. Это предполагает не только наличие линии с высокой физической скоростью передачи данных, но и требует также оперативного предоставления доступа к шине данных CAN, если нескольким блокам управления необходимо одновременно передать сообщения.
В целях разграничения передаваемых по шине данных CAN сообщений по степени срочности для отдельных сообщений предусмотрены различные приоритеты. Угол опережения зажигания, например, имеет очень высокий приоритет, значения пробуксовки — средний, а температура наружного воздуха — низший приоритет. Приоритет, с которым сообщение передаётся по шине данных CAN, определяет идентификатор (адрес) соответствующего сообщения.
Идентификатор, соответствующий меньшему двоичному числу, имеет более высокий приоритет, и наоборот (чем больше нулей в идентификаторе (битов нулевых) тем больше приоритет). Протокол шины данных CAN основывается на двух логических состояниях: биты являются или «рецессивными» (логическая «1» — единица), или «доминантными» (логический «О» — ноль).
Если доминантный бит передаётся как минимум одним модулем шины, то рецессивные биты, передаваемые другими модулями, перезаписываются.
Для примера: Когда несколько блоков управления начинают одновременную передачу данных, то конфликт доступа к шине данных разрешается посредством «побитового арбитража запросов общего ресурса»с помощью соответствующих идентификаторов.
При передаче «поля идентификатора» блок-передатчик после каждого бита проверяет, обладает ли он ещё правом передачи, или уже другой блок управления передаёт по шине данных CAN сообщение с более высоким приоритетом. Если передаваемый первым блоком-передатчиком рецессивный бит перезаписывается доминантным битом другого блока- передатчика, то первый блок-передатчик утрачивает своё право передачи (арбитраж) и становится блоком-приёмником.
Первый блок управления (N 1) утрачивает арбитраж с 3-го бита.
Третий блок управления (N 3) утрачивает арбитраж с 7-го бита.
Второй блок управления (N 2) сохраняет право доступа к шине данных CAN и может передавать свое сообщение.
Другие блоки управления могут передавать свои сообщения по шине данных CAN только после того, как она освободится.
При этом право передачи опять будет предоставляться в соответствии с приоритетностью сообщения по шине данных CAN.
То есть, при использовании этого принципа «приоритетности», на шине данных CAN не должно происходить конфликта, если одновременно несколько устройств выставили различные логические уровни.
Виды существующих шин
(на примере VW, Audi, Opel, Mercedes)
Шина CAN силового агрегата (быстрая шина), позволяющая передавать информацию со скоростью 500 кбит/с. Она служит для связи между блоками управления на линии двигателя и трансмиссии.
Шина CAN системы «Комфорт» (медленная шина), позволяющая передавать информацию со скоростью 100 кбит/с. Она служит для связи между блоками управления, входящими в систему «Комфорт».
Виды шин по классификации Mercedes:
Шина CAN-С – «быстрая» шина силового агрегата.
Шина CAN-B – «медленная», салонная шина «комфорт».
Шина CAN-D – диагностическая шина (используется для диагностики).
В автомобилях, имеющих диагностику по CAN шине, в качестве шлюза всех трёх шин установлен блок ZGW (центральный интерфейс). Это на более современных Мерседесах с 2002 года выпуска.
Цветовая маркировка шин на Mercedes
«Быстрая» шина силового агрегата (500 кб/сек) – зелёный и зелёный с белой полосой.
Шина «комфорт» — коричневый и коричневый с чёрной полосой.
На рисунках в различного рода руководствах и справочниках, провода шин CAN, для наглядности, могут быть обозначены приблизительно таким образом:
Общими для всех систем является следующее:
- Системы выполняют одинаковые предписания по передаче данных, сформулированные в соответствующем протоколе.
- Для передачи сигналов используются два скрученных между собой провода (Twisted Pair),которые эффективно противостоят внешним помехам (например, такая необходимость существует при их расположении в моторном отсеке).
- Один и тот же сигнал передается трансивером блока управления через оба провода шины, но на различных уровнях напряжения; только в дифференциальном усилителе принимающего блока управления формируется единый (разностный и очищенный от помех) сигнал, поступающий на вход шины CAN принимающего блока управления (Шина дифференциальная и работает только за счёт разницы напряжений между линиями, а не между линией и корпусом автомобиля. Многие «тыкаются» относительно «массы» и удивляются:
Искал и нашел 12 вольт на медленной шине относительно кузова, откуда?!! Ведь в спецификациях написано 2,5 — 3,5 вольта?).
Области применения шины данных CAN
(применительно к Mercedes)
Для моторного отсека и салона применяются различные шинные системы CAN, которые отличаются друг от друга скоростью передачи данных.
Скорость передачи по шине данных CAN моторного отсека (CAN-С) составляет 500 Кбит/с, а шина данных CAN салона (CAN-B) вследствие меньшего количества особо срочных сообщений обладает гораздо меньшейскоростью передачи данных — 83 Кбит/с.
Обмен данными между обеими шинными системами осуществляется через так называемые «межсетевые шлюзы», т.е. блоки управления, подключенные к обеим шинам данных.
CAN-C (шина данных CAN моторного отсека)
В оконечном блоке управления с каждой стороны установлен так называемый согласующий резистор шины данных с сопротивлением 120 Ком, подключённый между обеими проводами шины данных.
Шина данных CAN моторного отсека активирована только при включенном зажигании.
CAN-B (шина данных CAN салона)
Некоторые блоки управления, подключённые к шине данных CAN салона, активируются независимо от включения зажигания (например, система центральной блокировки).
Поэтому шина данных салона должна находиться в режиме функциональной готовности даже при выключенном зажигании (то есть, возможность передачи пакетов данных должна быть обеспечена и при выключенном зажигании).
Для максимально возможного снижения энергопотребления в состоянии покоя шина данных CAN переходит в режим «пассивного ожидания» при отсутствии передаваемых пакетов данных и активируется снова только при последующем доступе к ней.
Если в режиме «пассивного ожидания» шины данных CAN салона какой-либо блок управления (например, потолочная блок-панель управления (N70) передаёт сообщение по шине данных CAN, то его принимает только ведущий системный модуль (например, блок управления EZS (N73)
Соответствующий ведущий блок управления сохраняет это сообщение в памяти и посылает сигнал активации («Wake-up») на все блоки управления, подключённые к шине данных CAN салона.
При выполнении активации блок управления (N73) проверяет наличие всех абонентов шины данных CAN, после чего передаёт сохранённое ранее в памяти сообщение.
Топология шины CAN
Схема соединения шины CAN называется «топологией».
Или: «набор определенных правил, по которым к шине подключаются различные устройства».
Она зависит от модели конкретного автомобиля и Производителя.
Например, звездообразная топология запатентованная фирмой Daimler-Benz. Эта топология позволяет уменьшить резонансные проблемы в линии.
CAN контроллеры соединяются с помощью шины, которая имеет как минимум два провода CAN H и CAN L , по которым передаются сигналы при помощи специализированных ИМС приемо-передатчиков. Кроме того, ИМС приемо- передатчиков реализуют дополнительные сервисные функции:
- Регулировка скорости нарастания входного сигнала путем изменением тока на входе.
- Встроенная схема ограничения тока защищает выходы передатчиков от повреждения при возможных замыканиях линий CAN_H и CAN_L с цепями питания , а также от кратковременного повышения напряжения на этих линиях.
- Внутренняя тепловая защита.
- Режим пониженного энергопотребления, в котором приемники продолжают сообщать контроллеру о состоянии шины для того, чтобы при обнаружении на шине информационных сигналов он мог вывести приемопередатчики в нормальный режим работы.
Наиболее широкое распространение получили два типа приемоперадатчиков (трансиверов):
- «High Speed» приемопередатчики (ISO 11898-2),
- «Fault Tolerant» приемопередатчики
Трансиверы, выполненные в соответствии со стандартом
«High-Speed» (ISO11898-2), наиболее просты, дешевы и дают возможность передавать данные со скоростью до 1 Мбит/c.
«Fault-Tolerant» приемопередатчики (не чувствительные к повреждениям на шине) позволяют построить высоконадежную малопотребляющую сеть со скоростями передачи данных не выше 125 кбит/c.
ПРАКТИЧЕСКАЯ РАБОТА
Теперь, когда мы немного ознакомились с понятием «шина данных CAN», можно коротко рассказать о том, как проводилась практическая работа по обнаружению и устранению неисправности шины данных CAN на автомобиле Mercedes ML350 рейстанлинговой модели.
Ошибка была такая:
Этот автомобиль попал в Россию из Америки, был привезен на продажу, дефект оказался непонятным и «плавающим»: «автомобиль может 15-20 минут работать нормально, а потом на панели загорается значок BAS ESP и отключается вся шина данных».
Эти практические занятия проводились по учебному плану «Мастер-класс Mercedes» в компании BrainStorm, занятия проводил Дереновский Максим Васильевич (на фото вверху он слева: снимает разъем моторного блока).
До этого момента автомобиль уже пытались ремонтировать в другой мастерской. Там поменяли «по показаниям» (?) блок BAS ESP, что не помогло устранить неисправность.
Тогда им посоветовали «прокинуть» два провода шины CAN минуя крыло автомобиля.
(Эта неисправность – гниение проводов на этом крыле и выход их из строя, является конструктивно-технологической недоработкой фирмы).
Тоже не помогло. И тогда автомобиль был доставлен на эти практические занятия с целью найти и устранить неисправность.
Для поиска неисправности применили два рекомендуемых метода:
- Проверка шины CAN по сопротивлению
- Поочередное отключение блоков схемы
Проверка по сопротивлениям
Шина представляет собой два провода витой пары.
Образно: «имеет начало и конец», которыми являются какие-либо два блока. В этих конечных блоках находятся согласующие сопротивления («терминаторы»,- разг.), номиналом 120 Ом.
Следовательно:
- Если шина исправна и оконечные блоки подключены, то на шине мы увидим сопротивление 60 Ом (два по 120 в параллель).
- Если есть обрыв на одном из конечных блоков — шина будет звониться 120 Ом, и более 120 Ом, если конечных блоков нет вообще.
Подключенные в параллель блоки мультиметром (по сопротивлению) не контролируются.
В ML350 один из конечных блоков будет моторный, второй, в зависимости от года выпуска, вероятнее всего AAM, EAM или EZS.
Другие проверки
Определение КЗ (короткого замыкания) в шине данных CAN – определенно сложная задача. Как можно поступить:
- Визуально осмотреть провода с целью выявления и определения внешних повреждений
- Расстыковать разъемы блоков управления и проверить, не погнуты ли контактные штифты в одном и втором разъеме, не попали ли туда посторонние предметы (грязь, кусочки проводов и т.д)
- Попробовать локализовать поиск неисправности и разделить шину данных CAN на короткие участки, последовательно проверяя каждый из них
Отключение блоков
Одним из обучаемых было предложено начать проверку с отключения стеклоподъемников: «Он же на CAN «висит».
Неправильно. Стеклоподъемники «висят» на «медленной» шине и даже «если сильно захотят», все-равно «не положат «быструю» шину».
Начали отключать другие блоки по «быстрой» шине. Их достаточно много…
На блоке EGS (управление коробкой), расположеный справа в ногах у водителя, было, как обычно, обнаружено масло.
Именно масло иногда является причиной неисправности этого блока.
Откуда оно там появляется – трудно сказать, но как вариант, — « согласно «эффекта каппилярности» масло из коробки поднимается по проводам и через неплотности уплотнений просачивается и на блок и вовнутрь его, привнося ошибку».
Эта ошибка конструктивная: некачественные уплотнения жгута проводов к соленоидам в коробке АКПП. По жгуту оно и поднимается в электронный блок.
Блок ААМ – тоже оказался исправным.
Кстати, если уж заговорили о нем:
- по причине «программного сбоя», у него часто «слетает» радиоканал ключей зажигания. После «перезаливки» блока работоспособность восстанавливается.
- Может «слететь» роллинг ключей ( автомобиль не запускается, не видит ключа)
Виной «слёта» не только радиоканала , но и роллинга самих ключей , могут быть проблемы с питанием. Прокрутка двигателя на слабом аккумуляторе, плавная «посадка» АКБ на автомобиле , клеммы и т.д.
Но сама шина такой «слёт» не вызовет. Максимум сигнал разрешения запуска от блока ААМ не дойдёт до моторного и не будет включен даже стартер.
Отключение блоков тоже ничего не дало.
Проверили номера блока, которого заменили – все нормально, хотя тут тоже может быть путаница, так как существуют три варианта спецификаций для заказа:
— номер фирмы Mercedes
— номер BOSCH
— внутризаводской номер
Кодировки
Это достаточно важный момент, который нельзя упускать при проведении Диагностики.
Что такое «кодировки» для автомобиля:
Если просто, то это «единый язык, на котором блоки управления могут «разговаривать» между собой.
И так как автомобиль пришел из другой мастерской, а нам вообще неизвестна его история «жизни и ремонта», то проверять пришлось все кодировки.
И узнали, что в приборном щитке было прописано, что «BAS не интегрирован в ESP».
Сделали наоборот – «BAS интегрирован в ESP», перезапустили систему управления и ошибка С1020 перестала появляться.
Какой можно сделать вывод: причиной неисправности С1020 на данном автомобиле явилась неправильно закодированная комплектация автомобиля.
Однако не стоит считать, что «ошибка по CAN» является простойи её можно быстро найти и быстро устранить.
Как раз наоборот.
Как говорят специалисты: «Это «головняк» и разобраться с ним можно только при отличном знании «психологии Mercedes».
Это на бумаге и в этой статье вся работа по определению неисправности уложилась в несколько строчек.
В жизни все намного труднее, сложнее и длиннее…
ШОПИН А.В
© Легион-Автодата
Информационный центр компании BrainStorm
Апрель 2009 г.
Комментарии к статье: http://forum.autodata.ru/7/12832/
Вас также может заинтересовать:
Диагностика и ремонт: CAN — шина
Шина CAN системы «Комфорт»
Шина CAN — это страшно?
Всех приветствую, сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…
CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.
Основные характеристики протокола CAN:
- очень высокая надежность и защищенность
- каждое сообщение имеет свой собственный приоритет
- реализован механизм обнаружения ошибок
- автоматическая повторная отправка сообщений, которые были доставлены с ошибкой
- уже упомянутый широковещательный характер передачи данных
- возможность присутствия нескольких ведущих (master) устройств в одной сети
- широкий диапазон скоростей работы
- высокая устойчивость интерфейса к помехам
- кроме того, есть механизм обнаружения «сбойных» узлов с последующим удалением таких узлов из сети.
Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь. С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».
Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна ) Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:
| Скорость | Длина линии |
|---|---|
| 1 Мбит/с | 50 м |
| 500 кбит/с | 100 м |
| 125 кбит/с | 500 м |
| 10 кбит/с | 5 км |
Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:
Сначала немного о том, что же такое эта шина и как она выглядит:
Шина данных CAN – это обычная «витая пара», вот как на фото справа. Это специально скрученный двухжильный провод.
К этой витой паре подключены различные блоки управления – их называют «пользователи». Передача данных идет одновременно по двум проводам этой «витой пары». Важно знать, что логические уровни шины имеют зеркальное отображение: если по одному проводу передается уровень логического «нуля», то по другому проводу одновременно передается уровень логической «единицы».
Почему используется двухпроводная схема передачи данных:
- для стабильности распознавания ошибок
- для увеличения и повышения надёжности работы по передаче данных
Предположим, что пик напряжения возникнет только на одном проводе (например, вследствии проблем по электромагнитной совместимости).
И тогда блоки-приёмники могут идентифицировать это как ошибку и проигнорировать данный пик напряжения.
Если же произойдет короткое замыкание или обрыв одного из двух проводов, то благодаря интегрированной программно-аппаратной концепции надёжности произойдёт переключение в режим работы по однопроводной схеме, и повреждённая передающая линия использоваться не будет.
Так вот, продолжим о «уменьшении количества соединений между устройствами шины CAN»:
- Провода от датчиков проводятся только к ближайшему блоку управления, который преобразует измеренные значения в пакет данных и передаёт его на шину данных CAN.
- Уменьшение количества штекерных соединений
- Уменьшение количества контактных выводов на блоках управления
- Сигналами с одного датчика (например, с датчика температуры охлаждающей жидкости) могут воспользоваться различные системы
Пакет данных шины CAN
А сейчас давайте посмотрим, что представляет из себя «пакет данных» шины CAN. Он состоит из семи последовательных полей (отрезков).
На приведенном внизу рисунке показано восемь полей, последнее Intermission– «Пауза между пакетами данных» и оно не входит в Data Frame:
Цифры в каждом поле показывают количество битов, используемых в каждом сообщении (пакете данных).
Описание полей пакета данных<
Start of Frame
Маркирует начало сообщения (стартов, бит) и синхронизирует все модули шины.
Arbitration Field
Это поле состоит из идентификатора адреса в 11 бит и 1 контрольного бита и запрос (Remote Transmission Request-Bit).
Этот контрольный бит маркирует пакет как Data Frame (фрейм сообщения) или как Remote Frame (фрейм запроса) без байтов данных.
Control Field (управл. биты)
Поле управления (6 бит) содержит бит IDE (Identifier Extension Bit) для распознавания стандартного и расширенного формата, резервный бит для последующих расширений и — в последних 4 битах — количество байтов данных, заложенных в Data Field (поле данных).
Data Field (данные)
Поле данных может содержать от 0 до 8 байт данных. Сообщение по шине данных CAN длиной 0 байт используется для синхронизации распределённых процессов
CRC Field (контрольное поле)
Поле CRC (Cyclic-Redundancy-Check Field) содержит 16 бит и служит для контрольного распознавания ошибок при передаче данных.
АСК Field (подтверждение приема)
Поле АСК (Acknowledgement Field) содержит сигнал квитирования всех блоков-приёмников, получивших сообщение по шине данных CAN без ошибок (квитирование — подтверждение приема, отправка квитанции — управляющее сообщение или сигнал, выдаваемые в ответ на принятое сообщение).
End of Frame (конец фрейма)
Маркирует конец пакета данных
Intermission (интервал)
Интервал между двумя пакетами данных. Интервал должен составлять не менее 3 битов. После этого любой блок управления может передавать следующий пакет данных.
IDLE (режим покоя)
Если ни один блок управления не передаёт сообщений, то шина данных CAN остается в режиме покоя до передачи следующего пакета данных.
Прием и передача данных
Шина данных CAN является двунаправленной шиной — любой из подключённых блоков может, как передавать, так и принимать сообщения.
На приведенном выше рисунке слово Dashboard можно заменить на привычное (разговорное и чаще применяемое) «Шлюз».
К примеру на некоторых автомобилях, шлюзом между быстрой и медленной шиной является панель приборов (Ауди,Фольксваген), у Мерседеса функции шлюза выполняет EZS (замок зажигания), хотя сама панель работает в двух сетях, для отображения как салонной, так и моторной информации.
На следующих поколениях автомобилей с 2002 года начали использовать отдельный блок ZGW (центральный интерфейс), который выполняет функции шлюза, хранит кодировки комплектации авто и через него работает диагностика по CAN шине (именно по «чистому» CAN – без к-линий).
Шины данных CAN существуют с различными скоростями передачи данных и их иногда называют «быстрая шина» (High-Speed-CAN) и «медленная шина» (Low- Speed-CAN).
Например, High-Speed-CAN – это шина двигателя, АКПП и т.п., имеет скорость передачи данных 500 Кбит
Low-Speed-CAN — это шины для управления стеклоподъемниками, кондиционером и т.п. , со скоростью передачи данных 100 Кбит.
Порядок и формат передачи и приёма сообщений пользователями определён в протоколе обмена данных.
Существенным отличительным признакомшины данных CAN по сравнению с другими шинными системами, базирующимися на принципе абонентской адресации, является соотнесённая с сообщением адресация.
- каждому сообщению по шине данных CAN присваивается его постоянный адрес (идентификатор), маркирующий содержание этого сообщения (например: температура охлаждающей жидкости).
- протокол шины данных CAN допускает передачу до 2048 различных сообщений, причём адреса с 2033 по 2048 являются постоянно закреплёнными. Объём данных одного сообщения по шине данных CAN составляет 8 байт.
Блок-приёмник обрабатывает только те сообщения(пакеты данных), которые сохранены в его списке принимаемых по шине данных CAN сообщений (контроль назначения сообщения).
Пакеты данных могут передаваться только в том случае, если шина данных CAN свободна (то есть, если после передачи последнего пакета данных последовал интервал в 3 бита, и никакой из блоков управления не начинает передавать сообщение). При этом логический уровень шины данных является рецессивным (логическая «1»)
Шина данных CAN: РАСШИРЕННЫЕ ВОЗМОЖНОСТИ проведения Диагностики
Так как сигналы с одного датчика (например, датчика температуры, датчика скорости и др.), может использоваться различными системами, то в том случае, если наличие неисправности отображают все использующие данный сигнал системы, неисправным является, как правило, датчик или блок управления, обрабатывающий его сигналы.
Если же сообщение о неисправности поступает только от одной системы, хотя данный сигнал используется и другими системами, то причина неисправности, в большинстве случаев, заключается в обрабатывающем этот сигнал блоке управления или сервомеханизме
Высокий уровень защиты передаваемых данных
Высокий уровень защиты передаваемых данных беспечивается даже при сильных помехах.
При этом обеспечивается высокая скорость передачи данных (до 1 Mbit/s)
За счет чего это достигается:
- Механизм обнаружения ошибок Механизм исправления ошибок
- Сохранение работоспособности при высоком уровне электромагнитных помех
- Распределение приоритетов команд
- Работа в реальном режиме времени
Распознавание ошибок
Помехи при передаче данных могут приводить к возникновению ошибок. Такие ошибки при передаче данных надо распознавать и устранять. Протокол шины данных CAN различает два уровня распознавания ошибок:
- механизмы на уровне Data Frame (фрейм сообщения)
- механизмы на уровне битов
Cyclic-Redundancy-Check:
на основе передаваемого по шине данных CAN сообщения модуль-передатчик рассчитывает контрольные биты, которые передаются вместе с пакетом данных в поле «CRC Field». Модуль-приёмник заново вычисляет эти контрольные биты на основе принятого по шине данных CAN сообщения и сравнивает их с контрольными битами, полученными вместе с этим сообщением.
Frame Check:
Этот механизм проверяет структуру передаваемого фрейма, то есть перепроверяются битовые поля с заданным фиксированным форматом и длина фрейма.
Распознанные функцией Frame Check ошибки обозначаются как ошибки формата.
Механизмы на уровне битов
Мониторинг
Каждый модуль при передаче сообщения отслеживает логический уровень шины данных CAN и на основе этого распознаёт различия между переданным и принятым битом. Благодаря этому обеспечивается надёжное распознавание глобальных и возникающих в блоке-передатчике локальных ошибок по битам.
Bit Stuffing:
В каждом пакете данных между полем «Start of Frame» и концом поля «CRC Field» должно быть не более 5 последовательных битов с одинаковой полярностью. После каждой последовательности из 5 одинаковых битов блок-передатчик добавляет в поток битов один бит с противоположной полярностью. Блоки- приёмники, в свою очередь, удаляют эти биты после приёма сообщения по шине данных CAN.
Механизм устранения ошибок
Если какой-либо модуль шины данных CAN распознаёт ошибку, то он прерывает текущий процесс передачи данных, отправляя сообщение об ошибке. Сообщение об ошибке состоит из 6 доминантных битов.
Благодаря этому сообщению об ошибке все подключённые к шине данных CAN блоки управления оповещаются о возникшей локальной ошибке и, соответственно, игнорируют переданное сообщение.
После короткой паузы все блоки управления снова смогут передавать сообщения по шине данных CAN, причём первым опять будет отправлено сообщение с наивысшим приоритетом (мотор, АКПП и т.п.).
Блок управления, чьё сообщение по шине данных CAN обусловило возникновение ошибки, также начинает повторную передачу своего сообщения (Automatic Repeat Request — автоматический повтор запроса).
ПРИОРИТЕТЫ шины данных CAN
«ПРИНЦИП ПРИОРИТЕТНОСТИ»
Если несколько блоков управления одновременно начинают передавать сообщения, то вступает в силу «принцип приоритетности», согласно которому сообщение по шине данных CAN с наивысшим приоритетом будет передаваться первымбез потери времени или битов (арбитраж доступа к шине данных).
Каждый блок управления, утрачивающий право арбитража, автоматически переключается на приём и повторяет свою попытку отправить сообщение только после того, как шина данных CAN снова освободится.
Кроме пакетов данных существует также пакет запроса определённого сообщения по шине данных CAN. В этом случае блок управления, который может предоставить запрашиваемый пакет данных, реагирует на изданный запрос.
Для обработки данных в режиме реального времени должна быть обеспечена возможность их быстрой передачи. Это предполагает не только наличие линии с высокой физической скоростью передачи данных, но и требует также оперативного предоставления доступа к шине данных CAN, если нескольким блокам управления необходимо одновременно передать сообщения.
В целях разграничения передаваемых по шине данных CAN сообщений по степени срочности для отдельных сообщений предусмотрены различные приоритеты. Угол опережения зажигания, например, имеет очень высокий приоритет, значения пробуксовки — средний, а температура наружного воздуха — низший приоритет. Приоритет, с которым сообщение передаётся по шине данных CAN, определяет идентификатор (адрес) соответствующего сообщения.
Идентификатор, соответствующий меньшему двоичному числу, имеет более высокий приоритет, и наоборот (чем больше нулей в идентификаторе (битов нулевых) тем больше приоритет). Протокол шины данных CAN основывается на двух логических состояниях: биты являются или «рецессивными» (логическая «1» — единица), или «доминантными» (логический «О» — ноль).
Если доминантный бит передаётся как минимум одним модулем шины, то рецессивные биты, передаваемые другими модулями, перезаписываются.
Для примера: Когда несколько блоков управления начинают одновременную передачу данных, то конфликт доступа к шине данных разрешается посредством «побитового арбитража запросов общего ресурса»с помощью соответствующих идентификаторов.
При передаче «поля идентификатора» блок-передатчик после каждого бита проверяет, обладает ли он ещё правом передачи, или уже другой блок управления передаёт по шине данных CAN сообщение с более высоким приоритетом. Если передаваемый первым блоком-передатчиком рецессивный бит перезаписывается доминантным битом другого блока- передатчика, то первый блок-передатчик утрачивает своё право передачи (арбитраж) и становится блоком-приёмником.
Первый блок управления (N 1) утрачивает арбитраж с 3-го бита.
Третий блок управления (N 3) утрачивает арбитраж с 7-го бита.
Второй блок управления (N 2) сохраняет право доступа к шине данных CAN и может передавать свое сообщение.
Другие блоки управления могут передавать свои сообщения по шине данных CAN только после того, как она освободится.
При этом право передачи опять будет предоставляться в соответствии с приоритетностью сообщения по шине данных CAN.
То есть, при использовании этого принципа «приоритетности», на шине данных CAN не должно происходить конфликта, если одновременно несколько устройств выставили различные логические уровни.
Виды существующих шин
(на примере VW, Audi, Opel, Mercedes)
Шина CAN силового агрегата (быстрая шина), позволяющая передавать информацию со скоростью 500 кбит/с. Она служит для связи между блоками управления на линии двигателя и трансмиссии.
Шина CAN системы «Комфорт» (медленная шина), позволяющая передавать информацию со скоростью 100 кбит/с. Она служит для связи между блоками управления, входящими в систему «Комфорт».
Виды шин по классификации Mercedes:
Шина CAN-С – «быстрая» шина силового агрегата.
Шина CAN-B – «медленная», салонная шина «комфорт».
Шина CAN-D – диагностическая шина (используется для диагностики).
В автомобилях, имеющих диагностику по CAN шине, в качестве шлюза всех трёх шин установлен блок ZGW (центральный интерфейс). Это на более современных Мерседесах с 2002 года выпуска.
Цветовая маркировка шин на Mercedes
«Быстрая» шина силового агрегата (500 кб/сек) – зелёный и зелёный с белой полосой.
Шина «комфорт» — коричневый и коричневый с чёрной полосой.
На рисунках в различного рода руководствах и справочниках, провода шин CAN, для наглядности, могут быть обозначены приблизительно таким образом:
Общими для всех систем является следующее:
- Системы выполняют одинаковые предписания по передаче данных, сформулированные в соответствующем протоколе.
- Для передачи сигналов используются два скрученных между собой провода (Twisted Pair),которые эффективно противостоят внешним помехам (например, такая необходимость существует при их расположении в моторном отсеке).
- Один и тот же сигнал передается трансивером блока управления через оба провода шины, но на различных уровнях напряжения; только в дифференциальном усилителе принимающего блока управления формируется единый (разностный и очищенный от помех) сигнал, поступающий на вход шины CAN принимающего блока управления (Шина дифференциальная и работает только за счёт разницы напряжений между линиями, а не между линией и корпусом автомобиля. Многие «тыкаются» относительно «массы» и удивляются:
Искал и нашел 12 вольт на медленной шине относительно кузова, откуда?!! Ведь в спецификациях написано 2,5 — 3,5 вольта?).
Области применения шины данных CAN
(применительно к Mercedes)
Для моторного отсека и салона применяются различные шинные системы CAN, которые отличаются друг от друга скоростью передачи данных.
Скорость передачи по шине данных CAN моторного отсека (CAN-С) составляет 500 Кбит/с, а шина данных CAN салона (CAN-B) вследствие меньшего количества особо срочных сообщений обладает гораздо меньшейскоростью передачи данных — 83 Кбит/с.
Обмен данными между обеими шинными системами осуществляется через так называемые «межсетевые шлюзы», т.е. блоки управления, подключенные к обеим шинам данных.
CAN-C (шина данных CAN моторного отсека)
В оконечном блоке управления с каждой стороны установлен так называемый согласующий резистор шины данных с сопротивлением 120 Ком, подключённый между обеими проводами шины данных.
Шина данных CAN моторного отсека активирована только при включенном зажигании.
CAN-B (шина данных CAN салона)
Некоторые блоки управления, подключённые к шине данных CAN салона, активируются независимо от включения зажигания (например, система центральной блокировки).
Поэтому шина данных салона должна находиться в режиме функциональной готовности даже при выключенном зажигании (то есть, возможность передачи пакетов данных должна быть обеспечена и при выключенном зажигании).
Для максимально возможного снижения энергопотребления в состоянии покоя шина данных CAN переходит в режим «пассивного ожидания» при отсутствии передаваемых пакетов данных и активируется снова только при последующем доступе к ней.
Если в режиме «пассивного ожидания» шины данных CAN салона какой-либо блок управления (например, потолочная блок-панель управления (N70) передаёт сообщение по шине данных CAN, то его принимает только ведущий системный модуль (например, блок управления EZS (N73)
Соответствующий ведущий блок управления сохраняет это сообщение в памяти и посылает сигнал активации («Wake-up») на все блоки управления, подключённые к шине данных CAN салона.
При выполнении активации блок управления (N73) проверяет наличие всех абонентов шины данных CAN, после чего передаёт сохранённое ранее в памяти сообщение.
Топология шины CAN
Схема соединения шины CAN называется «топологией».
Или: «набор определенных правил, по которым к шине подключаются различные устройства».
Она зависит от модели конкретного автомобиля и Производителя.
Например, звездообразная топология запатентованная фирмой Daimler-Benz. Эта топология позволяет уменьшить резонансные проблемы в линии.
CAN контроллеры соединяются с помощью шины, которая имеет как минимум два провода CAN H и CAN L , по которым передаются сигналы при помощи специализированных ИМС приемо-передатчиков. Кроме того, ИМС приемо- передатчиков реализуют дополнительные сервисные функции:
- Регулировка скорости нарастания входного сигнала путем изменением тока на входе.
- Встроенная схема ограничения тока защищает выходы передатчиков от повреждения при возможных замыканиях линий CAN_H и CAN_L с цепями питания , а также от кратковременного повышения напряжения на этих линиях.
- Внутренняя тепловая защита.
- Режим пониженного энергопотребления, в котором приемники продолжают сообщать контроллеру о состоянии шины для того, чтобы при обнаружении на шине информационных сигналов он мог вывести приемопередатчики в нормальный режим работы.
Наиболее широкое распространение получили два типа приемоперадатчиков (трансиверов):
- «High Speed» приемопередатчики (ISO 11898-2),
- «Fault Tolerant» приемопередатчики
Трансиверы, выполненные в соответствии со стандартом
«High-Speed» (ISO11898-2), наиболее просты, дешевы и дают возможность передавать данные со скоростью до 1 Мбит/c.
«Fault-Tolerant» приемопередатчики (не чувствительные к повреждениям на шине) позволяют построить высоконадежную малопотребляющую сеть со скоростями передачи данных не выше 125 кбит/c.
ПРАКТИЧЕСКАЯ РАБОТА
Теперь, когда мы немного ознакомились с понятием «шина данных CAN», можно коротко рассказать о том, как проводилась практическая работа по обнаружению и устранению неисправности шины данных CAN на автомобиле Mercedes ML350 рейстанлинговой модели.
Ошибка была такая:
Этот автомобиль попал в Россию из Америки, был привезен на продажу, дефект оказался непонятным и «плавающим»: «автомобиль может 15-20 минут работать нормально, а потом на панели загорается значок BAS ESP и отключается вся шина данных».
Эти практические занятия проводились по учебному плану «Мастер-класс Mercedes» в компании BrainStorm, занятия проводил Дереновский Максим Васильевич (на фото вверху он слева: снимает разъем моторного блока).
До этого момента автомобиль уже пытались ремонтировать в другой мастерской. Там поменяли «по показаниям» (?) блок BAS ESP, что не помогло устранить неисправность.
Тогда им посоветовали «прокинуть» два провода шины CAN минуя крыло автомобиля.
(Эта неисправность – гниение проводов на этом крыле и выход их из строя, является конструктивно-технологической недоработкой фирмы).
Тоже не помогло. И тогда автомобиль был доставлен на эти практические занятия с целью найти и устранить неисправность.
Для поиска неисправности применили два рекомендуемых метода:
- Проверка шины CAN по сопротивлению
- Поочередное отключение блоков схемы
Проверка по сопротивлениям
Шина представляет собой два провода витой пары.
Образно: «имеет начало и конец», которыми являются какие-либо два блока. В этих конечных блоках находятся согласующие сопротивления («терминаторы»,- разг.), номиналом 120 Ом.
Следовательно:
- Если шина исправна и оконечные блоки подключены, то на шине мы увидим сопротивление 60 Ом (два по 120 в параллель).
- Если есть обрыв на одном из конечных блоков — шина будет звониться 120 Ом, и более 120 Ом, если конечных блоков нет вообще.
Подключенные в параллель блоки мультиметром (по сопротивлению) не контролируются.
В ML350 один из конечных блоков будет моторный, второй, в зависимости от года выпуска, вероятнее всего AAM, EAM или EZS.
Другие проверки
Определение КЗ (короткого замыкания) в шине данных CAN – определенно сложная задача. Как можно поступить:
- Визуально осмотреть провода с целью выявления и определения внешних повреждений
- Расстыковать разъемы блоков управления и проверить, не погнуты ли контактные штифты в одном и втором разъеме, не попали ли туда посторонние предметы (грязь, кусочки проводов и т.д)
- Попробовать локализовать поиск неисправности и разделить шину данных CAN на короткие участки, последовательно проверяя каждый из них
Отключение блоков
Одним из обучаемых было предложено начать проверку с отключения стеклоподъемников: «Он же на CAN «висит».
Неправильно. Стеклоподъемники «висят» на «медленной» шине и даже «если сильно захотят», все-равно «не положат «быструю» шину».
Начали отключать другие блоки по «быстрой» шине. Их достаточно много…
На блоке EGS (управление коробкой), расположеный справа в ногах у водителя, было, как обычно, обнаружено масло.
Именно масло иногда является причиной неисправности этого блока.
Откуда оно там появляется – трудно сказать, но как вариант, — « согласно «эффекта каппилярности» масло из коробки поднимается по проводам и через неплотности уплотнений просачивается и на блок и вовнутрь его, привнося ошибку».
Эта ошибка конструктивная: некачественные уплотнения жгута проводов к соленоидам в коробке АКПП. По жгуту оно и поднимается в электронный блок.
Блок ААМ – тоже оказался исправным.
Кстати, если уж заговорили о нем:
- по причине «программного сбоя», у него часто «слетает» радиоканал ключей зажигания. После «перезаливки» блока работоспособность восстанавливается.
- Может «слететь» роллинг ключей ( автомобиль не запускается, не видит ключа)
Виной «слёта» не только радиоканала , но и роллинга самих ключей , могут быть проблемы с питанием. Прокрутка двигателя на слабом аккумуляторе, плавная «посадка» АКБ на автомобиле , клеммы и т.д.
Но сама шина такой «слёт» не вызовет. Максимум сигнал разрешения запуска от блока ААМ не дойдёт до моторного и не будет включен даже стартер.
Отключение блоков тоже ничего не дало.
Проверили номера блока, которого заменили – все нормально, хотя тут тоже может быть путаница, так как существуют три варианта спецификаций для заказа:
— номер фирмы Mercedes
— номер BOSCH
— внутризаводской номер
Кодировки
Это достаточно важный момент, который нельзя упускать при проведении Диагностики.
Что такое «кодировки» для автомобиля:
Если просто, то это «единый язык, на котором блоки управления могут «разговаривать» между собой.
И так как автомобиль пришел из другой мастерской, а нам вообще неизвестна его история «жизни и ремонта», то проверять пришлось все кодировки.
И узнали, что в приборном щитке было прописано, что «BAS не интегрирован в ESP».
Сделали наоборот – «BAS интегрирован в ESP», перезапустили систему управления и ошибка С1020 перестала появляться.
Какой можно сделать вывод: причиной неисправности С1020 на данном автомобиле явилась неправильно закодированная комплектация автомобиля.
Однако не стоит считать, что «ошибка по CAN» является простойи её можно быстро найти и быстро устранить.
Как раз наоборот.
Как говорят специалисты: «Это «головняк» и разобраться с ним можно только при отличном знании «психологии Mercedes».
Это на бумаге и в этой статье вся работа по определению неисправности уложилась в несколько строчек.
В жизни все намного труднее, сложнее и длиннее…
ШОПИН А.В
© Легион-Автодата
Информационный центр компании BrainStorm
Апрель 2009 г.
Комментарии к статье: http://forum.autodata.ru/7/12832/
Вас также может заинтересовать:
Диагностика и ремонт: CAN — шина
Шина CAN системы «Комфорт»
Шина CAN — это страшно?
Всех приветствую, сегодняшняя статья будет целиком и полностью посвящена обзору протокола CAN. А в одной из следующих статей мы реализуем обмен данными по CAN на практике. Но не буду забегать вперед…
CAN (Controller Area Network) — это промышленный стандарт, позволяющий осуществить объединение в единую сеть различных узлов, механизмов, датчиков и т. п. Протокол является широковещательным, это значит, что все устройства в CAN-сети принимают все передаваемые по шине сигналы. Режим передачи данных — последовательный, при этом байты сообщений формируют кадры определенного вида. Структуру этих кадров данных мы также обязательно разберем в этой статье.
Основные характеристики протокола CAN:
- очень высокая надежность и защищенность
- каждое сообщение имеет свой собственный приоритет
- реализован механизм обнаружения ошибок
- автоматическая повторная отправка сообщений, которые были доставлены с ошибкой
- уже упомянутый широковещательный характер передачи данных
- возможность присутствия нескольких ведущих (master) устройств в одной сети
- широкий диапазон скоростей работы
- высокая устойчивость интерфейса к помехам
- кроме того, есть механизм обнаружения «сбойных» узлов с последующим удалением таких узлов из сети.
Первоначально стандарт был разработан для автомобильной промышленности. И занималась этим компания Bosch в 1980-х годах. Основная идея заключалась в том, чтобы уйти от использования огромного количества проводов, соединяющих многочисленные узлы автомобиля. И протокол CAN позволил этого достичь. С тех пор CAN является основным механизмом соединения устройств, узлов и датчиков автомобиля между собой. Помимо этого, интерфейс CAN активно используется в промышленной автоматизации, а также в системах «умного дома».
Давайте перейдем к физическому уровню протокола. В интернете можно найти много противоречивой информации на этот счет, но истина тут одна ) Стандарт CAN компании Bosch не регламентирует физический уровень передачи данных, поэтому могут использоваться абсолютно разные варианты, например, оптоволокно. На практике же чаще всего используется соединение посредством двухпроводной дифференциальной линии (витой пары). Ориентировочная максимальная длина линии для разных скоростей передачи данных составляет:
| Скорость | Длина линии |
|---|---|
| 1 Мбит/с | 50 м |
| 500 кбит/с | 100 м |
| 125 кбит/с | 500 м |
| 10 кбит/с | 5 км |
Важным условием работоспособности шины является наличие на концах витой пары согласующих резисторов, которые также называют терминаторами, с сопротивлением 120 Ом:
В отличие от многих других протоколов в CAN не рекомендуется описание битов данных как «логического нуля» и «логической единицы». Здесь используются понятия доминантный и рецессивный бит.
Важнейшим свойством является то, что если один из узлов сети хочет выставить на линии рецессивный бит, а другой доминантный, то в итоге на линии окажется доминантный бит. В общем-то отсюда и следует его название, от слова «доминировать» ) Очень хорошо этот процесс иллюстрирует пример с оптоволоконной линией. Как вы помните, в оптоволокне для передачи данных используется «свет», либо он есть (единица), либо его нет (ноль). При использовании в CAN-сети «свет» — доминантный бит, соответственно, отсутствие света или «темнота» — рецессивный.
Вспоминаем про важнейшее свойство передачи данных в сети. Пусть один узел выставляет на линии рецессивный бит, то есть «темноту». Второй узел, напротив, выставляет доминантный бит — «свет». В итоге на линии будет «свет», то есть доминантный бит, что в точности соответствует требованиям сети:
При использовании электрического сигнала устройство, желающее передать в линию доминантный бит, может подтянуть линию к земле. Это и приведет к тому, что на линии будет доминантный бит независимо от того, что выдают на линию другие участники коммуникации.
Это свойство используется для арбитража в сети CAN. Пусть несколько устройств хотят передать данные. Каждый из этих передатчиков сравнивает значение, которое он передает, со значением, фактически присутствующим на линии. В том случае, если передаваемое значение совпадает со считанным, устройство продолжает высылать свои данные. Если значения совпали у нескольких устройств, то все они продолжают передачу как ни в чем не бывало.
Продолжается это до того момента, когда значения станут различными. Если несколько устройств хотят передать рецессивный бит, а одно — доминантный, то в соответствии с правилом, которое мы обсудили выше, на линии окажется доминантный бит. В таком случае отправленные и считанные значения для устройств, пытающихся выдать на линию рецессивное состояние, не совпадут. В этом случае они должны прекратить передачу. А тот узел, который в этот момент передавал доминантный бит, продолжит свою работу. Доминирование в чистом виде )
Сигналы, которые передаются по витой паре, получили название CAN_H и CAN_L (High и Low). Доминантное состояние соответствует случаю, когда потенциал сигнала CAN_H выше потенциала CAN_L. Рецессивное — когда потенциалы равны (разница потенциалов не превышает допустимого отклонения, 0.5 В).
С этим вроде бы разобрались, давайте двигаться дальше! Пришло время определить, как биты объединяются в кадры. Протокол CAN определяет 4 вида кадров:
- Кадр данных (data frame)
- Кадр удаленного запроса (remote frame)
- Кадр перегрузки (overload frame)
- Кадр ошибки (error frame)
Для кадра данных возможны два варианта — базовый формат и расширенный. Вот так выглядит структура базового формата:
| Поле | Длина | Описание |
|---|---|---|
| Начало кадра (SOF) | 1 бит | Начало передачи кадра |
| Идентификатор (ID) | 11 бит | Идентификатор сообщения |
| Запрос на передачу (RTR) | 1 бит | Доминантный бит |
| Бит расширения идентификатора (IDE) | 1 бит | Бит определяет длину идентификатора, для базового формата — доминантный бит |
| Зарезервированный бит | 1 бит | Зарезервировано |
| Длина данных (DLC) | 4 бита | Количество байт данных |
| Данные | 0 — 8 байт | Данные |
| Контрольная сумма (CRC) | 15 бит | Контрольная сумма |
| Разграничитель контрольной суммы | 1 бит | Рецессивный бит |
| Промежуток подтверждения (ACK) | 1 бит | Для приемника — доминантный бит, для передатчика — рецессивный |
| Разграничитель подтверждения | 1 бит | Рецессивный бит |
| Конец кадра (EOF) | 7 бит | Все биты рецессивные |
А это структура расширенного:
| Поле | Длина | Описание |
|---|---|---|
| Начало кадра (SOF) | 1 бит | Начало передачи кадра |
| Идентификатор A (ID A) | 11 бит | Первая часть идентификатора |
| Подмена запроса на передачу (SRR) | 1 бит | Рецессивный бит |
| Бит расширения идентификатора (IDE) | 1 бит | Бит определяет длину идентификатора, для расширенного формата — рецессивный бит |
| Идентификатор B (ID B) | 18 бит | Вторая часть идентификатора |
| Запрос на передачу (RTR) | 1 бит | Доминантный бит |
| Зарезервированные биты | 2 бита | Зарезервировано |
| Длина данных (DLC) | 4 бита | Количество байт данных |
| Данные | 0 — 8 байт | Данные |
| Контрольная сумма (CRC) | 15 бит | Контрольная сумма |
| Разграничитель контрольной суммы | 1 бит | Рецессивный бит |
| Промежуток подтверждения (ACK) | 1 бит | Для приемника — доминантный бит, для передатчика — рецессивный |
| Разграничитель подтверждения | 1 бит | Рецессивный бит |
| Конец кадра (EOF) | 7 бит | Все биты рецессивные |
Результирующий идентификатор получается в результате объединения полей «Идентификатор A» и «Идентификатор B«.
Кадр удаленного запроса (remote frame) представляет из себя кадр данных, описанный выше, но без поля данных и с рецессивным битом RTR. Он используется в случае, когда один узел хочет запросить данные у другого узла.
Кадр ошибки (error frame) передает устройство, обнаружившее ошибку в сети. Фрейм ошибки имеет наивысший приоритет и принимается всеми устройствами сети в обязательном порядке.
Кадр перегрузки (overload frame) используется очень редко. Его идея и назначение заключаются в том, что с его помощью устройство, которое в данный момент не может принять данные, запрашивает повторную передачу этих же данных.
Давайте вернемся чуть назад, к арбитражу данных, и рассмотрим, что это может означать на практике. Итак, несколько устройств начинают передачу сообщения, а точнее кадра данных. Передается бит начала кадра и затем начинается передача идентификатора сообщения. Как вы помните, приоритет будет у того устройства, которое будет передавать доминантный бит, в тот момент, когда все остальные будут передавать рецессивный. То есть чем «позже» среди битов идентификатора появится «рецессивный бит», тем выше будет его приоритет. Другими словами: более высокий приоритет при использовании интерфейса CAN имеют сообщения с меньшим значением идентификатора.
Первые два типа кадров — кадр данных и кадр удаленного запроса — отделяются от других кадров специальным межкадровым промежутком (паузой). А для фреймов ошибки и перегрузки предусмотрена передача без пауз, чтобы обеспечить их скорейшую обработку узлами сети.
Итак, что у нас на очереди теперь? Конечно же контроль ошибок — важнейший аспект работы протокола CAN. Стандарт предусматривает несколько механизмов:
- Во-первых, это контроль передачи битов — уровень сигнала в сети сравнивается с передаваемым для каждого бита.
- Второй механизм заключается в использовании дополнительных битов (stuffing bit). После передачи любых пяти одинаковых битов автоматически добавляется передача бита противоположного значения. Таким образом, при передаче шести одинаковых битов диагностируется ошибка stuffing’а. Этот механизм используется для кодирования всех полей фреймов данных и запроса. Исключением являются только поля промежутка подтверждения, разграничителя контрольной суммы и EOF.
- Стандартная процедура проверки контрольной суммы. Передатчик вычисляет контрольную сумму для текущего кадра и передает ее в линию. В свою очередь, приемник также вычисляет контрольную сумму для принимаемых данных и сравнивает ее с тем значением, которое было отправлено передатчиком. В случае не совпадения значений диагностируется ошибка CRC.
- Также выполняется контроль битов фрейма, которые должны иметь заранее определенное значение. В случае, если реальное значение не совпадает с тем, которое ожидается, возникает ошибка.
Благодаря всем этим механизмам, вероятность необнаружения ошибки является очень низкой, что, конечно же, не может не радовать 👍
Кроме того, если один из узлов обнаружил ошибку в сообщении, он сообщает об этом в сеть CAN при помощи фрейма ошибки. А поскольку сеть у нас широковещательная, то о возникновении ошибки становится известно всем участникам коммуникации. И если в сообщении была обнаружена ошибка, его передача будет осуществлена еще раз.
И на этом еще не все! Каждый узел может находиться в одном из трех состояний:
- Error Active
- Error Passive
- Bus Off
Протокол CAN предусматривает, что изначально, после старта, узел находится в первом из этих состояний — Error Active. Каждое устройство имеет два счетчика ошибок:
- Счетчик ошибок передачи
- Счетчик ошибок приема
Существуют определенные правила обслуживания этих счетчиков, которые сводятся к следующему. Передатчик, обнаруживший ошибку, увеличивает свой счетчик ошибок передачи быстрее, чем приемники увеличивают свои счетчики ошибок приема. Это связано с предположением, что при ошибке, вероятность того, что сбой произошел именно в передатчике, а не в приемнике, достаточно велика. На практике ошибка передачи увеличивает соответствующий счетчик на 8, а ошибка приема лишь на 1. При приеме или передаче корректного сообщения как счетчик ошибок передачи, так и счетчики ошибок приема уменьшаются на 1.
Если значение любого из этих двух счетчиков узла превысит значение 127, то узел переходит в состояние Error Passive. А если величина одного из счетчиков превысит 255, то узел перейдет в состояние Bus Off.
Разница между этими состояниями заключается в действиях узла при диагностировании ошибки:
- Узел в состоянии Error Active при обнаружении ошибки передает в шину Active Error Flags — 6 доминантных бит. Поскольку биты доминантные, то это сообщение нарушает обычную работу шины и поэтому все устройства сети также фиксируют возникновение ошибки.
- Узел в состоянии Error Passive при обнаружении ошибки передает в шину Passive Error Flags — 6 рецессивных бит, которые игнорируются всеми другими участниками обмена. Поэтому увеличивается только величина счетчика ошибок одного конкретного узла.
- И, наконец, узел в состоянии Bus Off ничего не передает в сеть — ни фреймы ошибок, ни фреймы данных, ни какие-либо другие.
Как видите, протокол CAN крайне интересен для изучения, надежен, безопасен, и удобен в использовании. И на этой позитивной ноте на сегодня заканчиваем, скоро займемся практической реализацией протокола, также поговорим о микросхемах и устройствах, обеспечивающих работу с CAN. Так что подписывайтесь на обновления, буду рад снова видеть вас на нашем сайте 🤝
Промышленная сеть реального времени CAN представляет собой сеть с общей средой передачи данных. Это означает, что все узлы сети одновременно принимают сигналы передаваемые по шине. Невозможно послать сообщение какому-либо конкретному узлу. Все узлы сети принимают весь трафик передаваемый по шине. Однако, CAN-контроллеры предоставляют аппаратную возможность фильтрации CAN-сообщений.
Каждый узел состоит из двух составляющих. Это собственно CAN контроллер, который обеспечивает взаимодействие с сетью и реализует протокол, и микропроцессор (CPU).
Рис. 1. Топология сети CAN.
CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии — CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица — в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).
Типы сообщений сети CAN.
Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:
- Data Frame
- Remote Frame
- Error Frame
- Overload Frame
Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:
- поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
- для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
- для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)
Следует отметить, что поле идентификатора, несмотря на свое название никак не идентифицирует само по себе ни узел в сети, ни содержимое поля данных. Для Data кадра бит RTR всегда выставлен в логический ноль (доминантный сигнал).
- поле данных (data field) содержит от 0 до 8 байт данных
- поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
- слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.
Рис. 2. Data frame стандарта CAN 2.0A.
Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).
Error Frame — это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.
Overload Frame — повторяет структуру и логику работы Error кадра, с той разницей, что он используется перегруженным узлом, который в данный момент не может обработать поступающее сообщение, и поэтому просит при помощи Overload-кадра о повторной передаче данных. В настоящее время Overload-кадр практически не используется.
Контроль доступа к среде передачи (побитовый арбитраж).
Поле арбитража CAN-кадра используется в CAN для разрешения коллизий доступа к шине методом не деструктивного арбитража. Суть метода не деструктивного арбитража заключается в следующем. В случае, когда несколько контроллеров начинают одновременную передачу CAN кадра в сеть, каждый из них сравнивает, бит, который собирается передать на шину с битом, который пытается передать на шину конкурирующий контроллер. Если значения этих битов равны, оба контроллера передают следующий бит. И так происходит до тех пор, пока значения передаваемых битов не окажутся различными. Теперь контроллер, который передавал логический ноль (более приоритетный сигнал) будет продолжать передачу, а другой (другие) контроллер прервёт свою передачу до того времени, пока шина вновь не освободится. Конечно, если шина в данный момент занята, то контроллер не начнет передачу до момента её освобождения.
Рис. 3. Побитовый арбитраж на шине CAN.
Методы обнаружения ошибок.
CAN протокол определяет пять способов обнаружения ошибок в сети:
- Bit monitoring
- Bit stuffing
- Frame check
- ACKnowledgement Check
- CRC Check
Bit monitoring — каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.
Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.
Frame Check — некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Т.е. протокол CAN точно определяет какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.
ACKnowledgement Check — каждый узел получив правильное сообщение по сети посылает в сеть доминантный (0) бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.
CRC Check — каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы, не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.
Механизм ограничения ошибок (Error confinement).
Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.
Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.
Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).
Адресация и протоколы высокого уровня
В CAN не существует явной адресации сообщений и узлов. Протокол CAN нигде не указывает что поле арбитража (Identification field + RTR) должно использоваться как идентификатор сообщения или узла. Таким образом, идентификаторы сообщений и адреса узлов могут находится в любом поле сообщения (в поле арбитража или в поле данных, или присутствовать и там, и там). Точно также протокол не запрещает использовать поле арбитража для передачи данных.
Утилизация поля арбитража и поля данных, и распределение адресов узлов, идентификаторов сообщений и приоритетов в сети является предметом рассмотрений так называемых протоколов высокого уровня (HLP — Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.
Рис. 4. Логическая структура протокола CAN.
Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:
- DeviceNet
- CAL/CANopen
- SDS
- CanKingdom
Физичекий уровень протокола CAN
Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).
В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах — CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик — Phillips 82C250, который полностью соответствует стандарту ISO 11898.
Махимальная скорость сети CAN в соответствие с протоколом равна 1 Mbit/sec. При скорости в 1 Mbit/sec максимальная длина кабеля равна примерно 40 метрам. Ограничение на длину кабеля связано с конечной скоростью света и механизмом побитового арбитража (во время арбитража все узлы сети должны получать текущий бит передачи одновременно, те сигнал должен успеть распространится по всему кабелю за единичный отсчет времени в сети. Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:
| скорость передачи | максимальная длина сети |
| 1000 Кбит/сек | 40 метров |
| 500 Кбит/сек | 100 метров |
| 250 Кбит/сек | 200 метров |
| 125 Кбит/сек | 500 метров |
| 10 Кбит/сек | 6 километров |
Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.
Описание дефектов шины CAN 500kbps
Общие указания
Все представленные изображения действительны при соблюдении следующих условий:
— Канал «А» ( жёлтый цвет ) DSO подключается к проводу High шины CAN
— Канал «В» ( зелёный цвет ) DSO подключается к проводу Low шины CAN
— Массовые провода каналов «А» и «В» всегда подключены к массе автомобиля
Изображения для примера сделаны на автомобиле Audi Q7
Изображения реальных дефектов, как и их воздействие на автомобиль, могут отличаться от представленных в этом пособии.
Нормальный вид сигнала шины
Обрыв провода (пример: обрыв провода High)
КЗ провода на плюс (пример: КЗ провода High)
КЗ провода на массу (пример: КЗ провода Low)
КЗ проводов между собой
Перестановка проводов
Периодически уровни напряжения в канала High и Low меняются местами. Дефект проявляется немедленно после перестановки проводов.
Для некоторых автомобилей, например Audi Q5, данный дефект возможно не будет виден, так как БУ управляются через шину и при таком дефекте отключаются.
andkrass
Мастер советчик
-
#2
Массовые провода каналов «А» и «В» всегда подключены к массе автомобиля
извините , а можно пояснить сие ?? понимаю что глуп вопрос но все же .
Последнее редактирование: 08.03.2021
AKD2
Оракул
-
#3
Это хорошо, что понимаешь. Для полного фарша сперва надо было спросить, а что такое DSO?
Saulius
Оракул
-
#4
Digital Storage Oscilloscope.
AKD2
Оракул
-
#5
Digital Storage Oscilloscope.
С чего взял, что я это не знаю?
Saulius
Оракул
-
#6
С чего взял, что я это не знаю?
Я написал для незнающих, а на форуме таких много. Вот один вопрос и отпал.
AKD2
Оракул
-
#7
Я написал для незнающих, а на форуме таких много. Вот один вопрос и отпал.
Без понимания преобразования Фурье, понятии групповое время задержки, согласование сопротивлении, ширина полосы пропускания и т.п. анализировать сигнал при помощи осциллографа — занятие бесполезное.
Saulius
Оракул
-
#8
Без понимания преобразования Фурье, понятии групповое время задержки, согласование сопротивлении, ширина полосы пропускания и т.п. анализировать сигнал при помощи осциллографа — занятие бесполезное.
А это уже куча других вопросов.
BigHarry
Я здесь живу
-
#9
и т.п. анализировать сигнал при помощи осциллографа — занятие бесполезное.
То есть хотите сказать, что все эти уровни напряжения, их нижние и верхние пределы, которые разрисованы в первом сообщении темы — они типа ничего не значат, нужно помимо осциллограммы еще какие-то дополнительные вычисления производить типа преобразований Фурье или еще чего-то, что бы понять — работает шина или нет, так?
AKD2
Оракул
-
#10
Эти проблемы по CAN шине покажет VAG-COM в виде ошибок, дальше омметром-без него никак За исключением переполюсовки проводов, но это случай колхоза другого человека.
При поиске серьёзных проблем, нужны более-менее фундаментальные знания и хороший осциллограф, который правильно показывает фронты прямоугольного импульса.
Преобразование Фурье и прочее видно по осциллограмме, когда сумма (т.е. интеграл) гармоник (производная/дифференциал) составляющих прямоугольного импульса отличаются от идеальных по фазе и амплитуде. Получилось корявое объяснение, ну как смог..
andkrass
Мастер советчик
-
#11
То есть хотите сказать, что все эти уровни напряжения, их нижние и верхние пределы, которые разрисованы в первом сообщении темы — они типа ничего не значат, нужно помимо осциллограммы еще какие-то дополнительные вычисления производить типа преобразований Фурье или еще чего-то, что бы понять — работает шина или нет, так?
достаточно знать форму правильного сигнала , на мой взгляд.
BigHarry
Я здесь живу
-
#12
Эти проблемы по CAN шине покажет VAG-COM в виде ошибок
Хрен его знает, с замыканием на шине, как мне кажется, сканер вообще не подключится к ней. Я так понимаю, что осликом лезут на шину только в случаях, когда сканер уже не может, а если сканер работает, адекватно подключается и ответы получает — не вижу смысла в таком случае осциллом смотреть сигналы шины.
Есть, конечно, осциллы с анализаторами протоколов, там, конечно, информации и наглядности больше, но, как правило, стоят они не дешево.
-
Всех приветствую! В последнее время с машиной какой-то полтергейст творится.
Сначала думал, что проблема с мехатроником акпп. Теперь после тщательной диагностики БОШем выяснилось, что иногда теряется связь с Can-шиной, из-за этого отрубаются блоки управления, в том числе АКПП, полный привод и прочее….
Куда копать дальше???Е53, рест, 3.0 дизель
-
Наверное искать виновника, который «садит» шину… как вариант.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Что за КАНшина
,много ошибок по ней(доп.помпа,по шитку приборов,по ЛЦМ)?Где находится?
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Кан шина — это два провода, которые идут по всей машине. Находятся во многих жгутах.
При этом, это не единый кусок провода, а несколько коротких, которые спаяны в определнных местах.Если бы речь шла о e70, то в первую очередь нужно смотерть в правую нишу багажника, там как раз находятся места спаяки и туда часто попадает вода из люка.
Рекомендую попробовать поискать места спайки этой шины. -
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Авто с панорамой?
Проверяли наличие влаги под передними коврами? -
Авто без панорамы.Влага присутствует под ковром водителя(она всегда там за 4 года владения).Но глюки приборки и ЛЦМ(появились этой зимой) прекращаются после 2 часов нахождения «ветерка» в салоне.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Подними ковер, не поленись!
Просмотри большие жгуты. Там будет что-то похожее на пластиковые колпачки (это и есть содинители шины). -
Вы имели ввиду ковры,это напольное покрытие под ногами?Как эти соединения отражают информацию на диагностике?Будет в них плохое соединение или коррозия(вообщем плохой контакт),не выходила бы на связь?!
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
- Регистрация:
- 10 дек 2013
- Сообщения:
- 1,443
- Пол:
- Мужской
- Регион:
- Москва
Для справки
Шина CAN (Controller Area Network) представляет собой систему шин, при которой все подключенные станции равноправны, т.е. каждый блок управления может посылать и принимать сигналы. Проще говоря, подключенные блоки управления могут «общаться» друг с другом и обмениваться информацией посредством проводов.
Благодаря линейной структуре сети при выходе из строя одного ЭБУ для остальных блоков управления полностью сохраняется доступ к системе шин. Соединение состоит из двух проводов передачи данных (CAN_L и CAN_H), защищенных от помех экраном (CAN_S).
В настоящий момент эта система соединяет друг с другом блоки управления систем ЕGS, ASC/DSC, цифровую электронную систему управления двигателем (DME) и комбинацию приборов. В дальнейшем планируется подключение к ней других ЭБУ. ЭБУ систем EGS, ASC/DSC и DME обмениваются по шине CAN следующими сигналами:
•положение педали акселератора
•сигнал нагрузки
•частота вращения коленвала двигателя
•температура охлаждающей жидкости двигателя
•сигнал выключателя стоп-сигнала
•сигнал режима Kick-Down
•программа режима движения
•передача
•вмешательство в работу двигателя
•угловые скорости колес
•индикация положения рычага управления КПП и информация по программе
•индикация неисправности блока управления КПП
•километражПодключенные устройства должны иметь одинаковый уровень CAN. Проверку уровня CAN можно произвести через диагностический интерфейс. На идентификационной странице соответствующего блока управления, подключенного к шине CAN, выдается уровень CAN (индекс CAN).
Причины неисправности
Нарушение связи по шине CAN (то есть сообщения об ошибках связи по шинам в отдельных блоках управления) может иметь следующие причины:
— обрыв или короткое замыкание проводов связи.
— помехи в бортовой сети, например, вызванные неисправными катушками зажигания или соединениями с массой
— отказ всех модулей связи в отдельных блоках управления.
— отказ цепи подачи питания отдельных ЭБУ. К появлению сообщений о неисправности также может привести медленно падающее напряжение аккумуляторной батареи при почти разряженной батарее, так как не все блоки управления одновременно отключаются из-за слишком низкого напряжения питания.Согласующие резисторы
В двух блоках управления, подсоединенных к шине CAN, установлено по одному согласующему резистору 120 Ом между обоими проводами связи CAN-H и CAN-L. Тем самым в рамках объединения ЭБУ между обоими проводами связи измеряется сопротивление 60 Ом (параллельное включение). Благодаря этому с помощью адаптера можно легко проверить провода в одном из блоков управления. В отсоединенном состоянии можно непосредственно измерить сопротивление соответствующих блоков управления. Блоки управления без согласующих резисторов обычно показывают значение от 10 до 50 кОм.
Согласующие резисторы располагаются в ЭБУ системы ASC/DSC и, в зависимости от типа двигателя, либо в комбинации приборов, либо в системе управления двигателем.
Поиск неисправности
Отказ одного блока управления или модуля связи как правило вызывает занесение сообщения о неисправности в других блоках управления, подсоединенных к шине.
Отказ одного модуля связи в одном ЭБУ при определенных обстоятельствах может парализовать работу шины CAN, т.е. внести ошибку во все ЭБУ, подключенные к шине, при связи с ними.
В этом случае можно каждый раз отсоединять по одному ЭБУ, тогда по ЭБУ, остающимся подсоединенными к шине, распознается вышедший из строя ЭБУ (После отсоединения стереть информацию в ЗУ неисправностей, затем считать ЗУ неисправностей). Как только отсоединенным окажется неисправный ЭБУ, новые неисправности шины CAN относительно связи остающихся подсоединенными ЭБУ заноситься не будут.
Если однако по этому методу отсоединяются ЭБУ с согласующим сопротивлением, то отсутствующее теперь на шине согласующее сопротивление может точно также парализовать связь. Таким образом эта проверка не во всех случаях ведет к цели, однако в большинстве случаев очень полезна.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Спасибо
.Но все таки ,как определить на какой КАН шине висят блок ЛЦМ и приборка?
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
- Регистрация:
- 10 дек 2013
- Сообщения:
- 1,443
- Пол:
- Мужской
- Регион:
- Москва
Что значит «на какой»? Она одна, общая. И LCM на ней не висит.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Благодарю,надеюсь эти фото помогут в решении проблемы.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
кто нибудь решил эту проблему? с can
-
Решение проблемы в первом же ответе!
Другое дело как искать.
В первую очередь исключить все блоки на предмет неисправности по очереди отключая их. Если с ними всё в порядке, искать коротыш или внештатное устройство.
В моём случае электрик повесил на шину диод, подключив так, что когда есть коротыш — диод горит. После этого пошли лопатить всю проводку от предов до багажника.
Виновник был найден в левой нише.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
nelidov и Fanatics нравится это.
-
цена вопроса?? тоже самое и у меня твориться. после дождя лужа была спереди. почистил трубки люка. Ошибок море. по САN и ЕGS.
-
Ну разве моя цена вопроса что то тебе даст?
У нас даже разные страны проживания, я уже не говорю о том, что мастер делавший мне авто — мой сосед по квартире.
А вообще, не сильно кто хочет за такое браться, потому что если это не какой то блок или явный дефект, то провода в ручную лопатить можно довольно долго.
Дело только в ошибках или ещё как то проявляется? Что пишет по КАН?
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
точно не помню. завтра напишу. Если машина простоит 2-3 дня то абс ! и 4х4 работает в добавок аварийный режим коробки пишет. чуть покатаюсь гаснет всё. И на дороге резко так с газа бросает. Расход повысился. незнаю почему?может из за этого?
-
Ну сложно так что то сказать.
У меня были другие глюки по электрике.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
ike : сообщение о внутр.ошибке в блоке LM
ike : отсутствует идентификация САН ЕGS
ike : сигнальный продов ЕGS поврежден
dsc 3/4 отсутствует сообщение(блок управления коробкой передач 43А
блок управления кпп наружение связи PT-can
can_message dsc1
can timeout ЕGS 1 smg1 -
- Регистрация:
- 11 дек 2019
- Сообщения:
- 10
- Пол:
- Мужской
- Регион:
- Нижегородская обл.
ребят может по моей проблеме что подскажите! приехал заглушил машину через некоторое время ( 5-10 мин ) завел все хорошо было , машина по работала и сначала потухла магнитола потом климат потом сама заглохла! ключ вытащил вставил включились сами по себе дворники , и выключить их не могу , не включается печка не включается магнитола не работают стеклоподьемники, на кнопку старт не реагирует , только на панели по очереди вылетают множество ошибок
-
- Регистрация:
- 11 дек 2019
- Сообщения:
- 10
- Пол:
- Мужской
- Регион:
- Нижегородская обл.
-
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
-
В принципе Дэни уже все сказал там. Такой функционал к сожалению там не реализовать никак. Только сигнал на скоростной порог поставить можно.
Stop hovering to collapse…
Click to collapse…
Hover to expand…
Нажмите, чтобы раскрыть…
Сначала думал, что проблема с мехатроником акпп. Теперь после тщательной диагностики БОШем выяснилось, что иногда теряется связь с Can-шиной, из-за этого отрубаются блоки управления, в том числе АКПП, полный привод и прочее…. 
,много ошибок по ней(доп.помпа,по шитку приборов,по ЛЦМ)?Где находится?
.Но все таки ,как определить на какой КАН шине висят блок ЛЦМ и приборка?Поделиться этой страницей
На чтение 21 мин Просмотров 6.9к. Опубликовано 20.10.2022
Обновлено 20.10.2022
Из этой статьи вы узнаете, что такое CAN-шина, почему она появилась. Разберемся с блоками управления в автомобиле и с тем, как они общаются между собой. Расскажем, какие контроллеры соединяются быстрой CAN-шиной, а какие — медленной.
Узнаете, как устроена CAN-шина на физическом и цифровом уровне, из каких данных состоит сообщение, как происходит арбитраж трафика. Какая максимальная длина кабеля и скорость передачи информации, как реализована защита от помех.
Если интересует какой-то конкретный вопрос, пользуйтесь оглавлением.
Что такое CAN-шина?
Автомобиль подобен человеческому организму. Сеть контроллеров (шина CAN) это как нервная система у человека.
В свою очередь, «узлы» или «электронные блоки управления» (ЭБУ) подобны частям тела. Они соединены между собой через CAN-шину.
Шина CAN представляет собой витую пару проводов. С ее помощью все блоки управления в автомобиле соединены в единую информационную сеть.
Причины появления CAN-шины
Когда вы нажимаете выключатель в своем доме, чтобы включить свет, электричество проходит через выключатель к лампам.
Автомобили раньше использовали такое же подключение. С тех пор как в 1915 году Генри Форду пришла идея добавить в свои автомобили фары и электрический сигнал, электричество поступало от аккумулятора через выключатели к фарам и другим устройствам.
К 1960-м годам в каждом автомобиле были тысячи тяжелых проводов.
После нефтяного эмбарго 1970-х годов на автопроизводителей оказывалось все большее давление с целью повышения эффективности использования топлива. Поэтому они начали искать способы уменьшить вес выпускаемых автомобилей.
К началу 1980-х годов в автомобилях было все больше и больше электронных блоков управления. Сначала электронное управление получили самые важные системы, такие как системы управления двигателем, трансмиссией и тормозной системой. Но со временем электронное управление распространилось и на второстепенные либо периферийные системы, такие как климат-контроль, блоки комфорта и прочие.
В скором времени такое положение дел привело к тому, что производители столкнулись тремя проблемами:
Такие компании, как Bosch, искали тип шинной коммуникационной системы, которая могла бы использоваться в качестве системы связи между несколькими ЭБУ и системами автомобиля.
Они искали на рынке, но не могли найти именно то, что было нужно, поэтому они начали разработку «Controller Area Network» в партнерстве с Mercedes-Benz, Intel, а также несколькими университетами Германии.
Краткая история шины CAN
В 1986 году компания Bosch представила стандарт CAN на конгрессе SAE в Детройте. Год спустя корпорация Intel начала поставки первых микросхем контроллеров CAN, и автомобильный мир изменился навсегда.
- До CAN: автомобильные ЭБУ использовали сложную проводку «точка-точка».
- 1986: Компания Bosch разработала протокол CAN.
- 1991: Bosch опубликовала CAN 2.0 (CAN 2.0A: 11 бит, 2.0B: 29 бит).
- 1993: CAN принят в качестве международного стандарта (ISO 11898).
- 2003: ISO 11898 становится серией стандартов.
- 2012: Bosch выпустила CAN FD 1.0 (передачи данных на двух скоростях).
- 2015: Протокол CAN FD стандартизирован (ISO 11898-1).
- 2016: Физический уровень CAN для скоростей передачи данных до 5 Мбит/с стандартизирован в ISO 11898-2.
Теперь, например, достаточно одного датчика температуры, который подключен к блоку управления двигателем. ЭБУ опрашивает датчик температуры для себя и отправляет эту информацию в виде сообщения в информационную шину данных для других блоков.
При таком подходе уменьшается количество проводов, нет дублирования датчиков. Появляется возможность ввода/вывода информации из электронных блоков управления, что позволяет диагностировать сложные системы с множеством электронных блоков управления.
Сегодня CAN является стандартом в автомобилях (легковых, грузовых, автобусах, тракторах, …), кораблях, самолетах, электромобилях и многом другом.
Что такое ЭБУ?
В автомобиле ЭБУ могут быть, например, блок управления двигателем, подушками безопасности, аудиосистемой и т. д.
В современном автомобиле может быть до 70 ЭБУ — и каждый из них может иметь информацию, которой необходимо поделиться с другими участниками сети.
Именно здесь на помощь приходит CAN-шина. Она позволяет каждому блоку управления общаться со всеми другими ЭБУ без сложной специальной проводки.
В частности, блок управления может передавать данные с датчиков по шине CAN. Переданные данные принимаются всеми другими контроллерами в сети CAN, после чего каждый ЭБУ может проверить данные и решить, принимать их или игнорировать.
Физический уровень шины CAN
Физический уровень CAN описан в стандарте ISO 11898 и регламентирует способ передачи данных. В случае с CAN-шиной это два провода витой пары. При этом CAN-шина вполне может работать и по одному проводу, а витая пара прежде всего используется для защиты от помех.
Однопроводная схема
Для того чтобы лучше понять как данные передаются по двухпроводной CAN-шине, давайте сначала рассмотрим как данные передаются по однопроводной схеме, которой, например, является K-линия.
Итак, есть один провод, с его помощью соединены блоки управления. Этот провод внутри блока соединен с 12 вольтами через резистор 5 килоом. Таким образом напряжение на проводе становится по умолчанию 12 В.
Каждый из подключенных блоков может стягивать это напряжение на массу, меняя его с 12 на 0 вольт. Таким образом, получаются прямоугольные импульсы на шине данных. Они могут принимать всего два уровня напряжения — 0 и 12 вольт.
Присвоим низкому уровню в ноль вольт логический ноль, а уровню 12 вольт — логическую единицу. Зададим тактовый сигнал шины, то есть обозначим сколько раз секунду блоки будут опрашивать шину и соответственно сколько времени будет длиться один бит.
То есть наименьшая часть цифровой информации вид может принимать только два значения 0 или 1. Таким образом, мы получили физическую возможность отправлять и принимать двоичные данные между блоками управления.
Витая пара. Как работает CAN high-speed
В CAN-шине тот же принцип, только сигнал считывается как разница между напряжениями проводов CAN-high и CAN-low, которые образуют витую пару.
Чтобы понять, как именно это происходит, давайте рассмотрим как могут меняться уровни напряжения на этих проводах.
По умолчанию на проводе CAN-high, как и на проводе CAN-low, напряжение соответствует величине в 2,5 В. При этом разница напряжений между проводами составляет 0 В. Такое состояние can-шины называется рецессивным (recessive) и интерпретируется как логическая единица.
Существует и второе состояние шины, при котором напряжение на проводе CAN-high будет 3,5 вольт, а на проводе CAN-low — 1,5 В. Разница напряжений между проводами составит 2 вольта. Это состояние называется доминантным (dominant) и соответствует логическому нулю.
Логическая 1 (рецессивное состояние):
- 2,5 вольта на проводе CAN_H;
- 2,5 вольта на проводе CAN_L;
- дифференциальное напряжение 0 вольт.
Логический 0 (доминантное состояние):
- 3,5 вольта на проводе CAN_H;
- 1,5 вольта на проводе CAN_L;
- дифференциальное напряжение 2 вольта.
Так работает высокоскоростная шина CAN high speed. Она описана в стандарте ISO 11898-2.
Работа CAN low speed
Устройство низкоскоростной шины CAN low speed описано в стандарте ISO 11898-3. Для нее уровни напряжения такие.
Логическая 1 (рецессивное состояние):
- 0 вольт на проводе CAN_H;
- 5 вольт на проводе CAN_L;
- дифференциальное напряжение 5 вольт.
Логический 0 (доминантное состояние):
- 3,6 вольта на проводе CAN_H;
- 1,4 вольта на проводе CAN_L;
- дифференциальное напряжение 2,2 вольта.
Защита от помех
Ведь и на одном проводе все работало, так зачем усложнять?
CAN-шиной объединены самые ответственные блоки управления автомобиля. От качества этой связи напрямую зависит безопасность движения. В связи с этим CAN-шине предъявляются высокие требования к надежности и безотказности.
Дело в том, что многие компоненты автомобиля являются источниками электромагнитных помех. Особенно система зажигания.
Использование витой пары позволяет в значительной степени решить эту проблему. Давайте посмотрим, как это происходит.
Представьте себе, что витая пара CAN-шины попадает в зону действия электромагнитной помехи. В медном проводе индуцируется напряжение, которое плюсуется или отнимается от напряжения, уже существующего на этом проводе.
Предположим, что на проводе CAN-high в рецессивном состоянии напряжение было 2,5 В. Помеха увеличила его на 1,1 В. Соответственно мы получили напряжение в 3,6 В, которое могло быть интерпретировано уже как доминантное состояние.
Но CAN-шина устойчива к таким помехам, потому что сигналом является не просто изменение уровня напряжения на одном из проводов, а именно изменение разницы между напряжениями на этих проводах. А разница как раз не изменилась из-за применения витой пары.
Таким образом, на проводе CAN_L напряжение поднимется на те же 1,1 В. А разница напряжений как была 2,5 — 2,5 = 0 В, так и осталась 3,6 — 3,6 = 0 В. Действие помехи на шину в доминантном состоянии аналогично.
Зачем нужен трансивер
Название Transceiver произошло от двух слов receiver (приемник) и transmitter (передатчик). Переводится как приемопередатчик.
Трансиверы обрабатывают дифференциальный сигнал, принимают и передают информацию. Трансивер связывает провода витой пары (CAN_H и CAN_L) с линиями Tx и Rx микропроцессора, который не умеет напрямую работать с CAN-шиной.
По линии Tx микропроцессор отправляет информацию в шину данных, а по линии Rx он считывает информацию.
В трансивере находится схемотехника, которая формирует разные уровни напряжения на проводах CAN_H и CAN_L для доминантного и рецессивного состояния шины.
Трансивер обычно устанавливается внутри электронного блока управления и представляет собой специализированную микросхему.
Оконечные сопротивления
Это еще одна часть физического уровня CAN-шины. Оконечные сопротивления используются для борьбы с отраженным сигналом так называемым эхом.
Отраженный сигнал препятствует нормальной передаче данных. Причем, чем больше будет длина проводов шины и чем выше будет скорость передачи данных, тем значительней будет проявляться этот негативный эффект.
Правильно подобранные конечные нагрузочные сопротивления компенсируют отраженный сигнал. Обычно это два резистора по 120 ом внутри блока управления. Они подключены к противоположным концам шины. Таким образом, сопротивление между проводами can-шины составляет около 60 ом.
У разных автопроизводителей величина оконечных сопротивлений может отличаться.
Где применяется CAN high speed, а где CAN low speed
HS-CAN и LS-CAN отличаются скоростью передачи данных и уровнями рабочих напряжений. Быстрый CAN применяется для связи блоков управления двигателя, автоматической коробки передач, тормозов, рулевого управления, подушек безопасности, полного привода, пневмоподвески и других важных систем, от которых напрямую зависит безопасность движения.
Медленный CAN используется для менее важных систем, таких как климат-контроль, системы комфорта, наружное освещение, электропривод сидений и т. п. в зависимости от комплектации автомобиля.
Особенностью медленного CAN является возможность сохранять работоспособность в однопроводном режиме, если второй провод витой пары поврежден.
Высокоскоростной и низкоскоростной CAN автопроизводители могут называть по-своему, а также пользоваться любой из доступных скоростей передачи данных.
Межсетевой шлюз (CAN gateway)
Часто есть необходимость передавать информацию от блока управления, подключенного к быстрой CAN-шине, к блоку, подключенному к медленной CAN-шине, и наоборот. Например, блоку управления климатом нужно знать температуру двигателя.
Так как напрямую разные CAN-шины не соединить, для этих целей используется межсетевой шлюз (CAN gateway). К нему подключаются шины с разными скоростями. Это могут быть не только CAN-шины, но и другие шины, присутствующие в автомобиле, к примеру, FlexRay или Ethernet.
Часто в CAN gateway хранится информация об автомобиле, VIN номер и комплектация. Именно из него сканеры получают информацию при автоопределении автомобиля.
Сам межсетевой интерфейс может быть выполнен как отдельным блоком, так и встроен в другие блоки. Обычно это приборная панель, электронный замок зажигания или блок управления бортовой сети (Body Control Module — BCM).
Мы разобрались физическим уровнем CAN-шины. Теперь вы знаете, как напряжение на витой паре становится единицами и нолями, как биты передаются от одного блока управления к другому.
Канальный уровень CAN-шины (передача данных)
CAN является широковещательной шиной последовательной передачи данных. То есть данные отправляются по очереди бит за битом и при этом между узлами сети реализован один общий эфир, когда каждый слышит каждого.
Блоки управления, как и диагностический сканер, выступают узлами в сети CAN-шины. Но для того, чтобы все это заработало мало просто подавать в шину единицы и ноли. Нужно определить, какой узел будет говорить, какой слушать, каков будет формат сообщения, кому это сообщение адресовано и как будет подтверждаться правильность приема.
Эту задачу решает канальный уровень (data link layer), описанный в стандарте ISO 11898-1. Каждый узел может отправлять и принимать информацию кадр за кадром.
Существует четыре типа сообщений-кадров:
- Кадр данных (data frame). Передает информацию одному или нескольким узлам-приемникам.
- Кадр удаленного запроса (remote frame). Запрашивает данные у других узлов.
- Кадр ошибки (error frame). Сообщает об ошибках.
- Кадр перегрузки (overload frame). Сообщает о состоянии перегрузки.
Из чего состоит кадр CAN-шины
Рассмотрим структуру самого распространенного кадра Data frame.
SOF. Начало кадра
Первый бит кадра (SOF — Start Of Frame) всегда доминантный логический ноль. Он выводит шину из состояния холостого хода и начинает передачу данных.
Арбитражное поле
Дальше следует арбитражное поле. Оно используется для того, чтобы определить, какой из узлов получит доступ к вещанию по шине. Ведь передача данных последовательная, бит за битом, кадр за кадром. Соответственно узлам приходится ждать своей очереди для отправки сообщения в шину, но при этом слушают шину они постоянно.
Зачем нужен арбитраж CAN-шины
Арбитраж сообщений это процесс, в котором два или более CAN-контроллеров договариваются о том, кто должен использовать шину.
Любой узел может начать передачу данных, когда обнаружит незанятую шину. Это может привести к тому, что два или более контроллеров начнут передачу сообщения почти одновременно.
Нет такого блока, который будет вещать всегда первым. Первым всегда будет передавать информацию тот блок, чьё сообщение имеет наивысший приоритет. И как раз этот спор и решается в арбитражном поле. Разберемся как именно.
Как происходит арбитраж CAN-шины и что такое идентификатор
Представим, что есть три узла, которые одновременно хотят получить доступ к CAN-шине. После бита «Start Of Frame» каждый из этих блоков начинает отправлять биты идентификаторов в шину данных.
Идентификатор присвоен каждому сообщению и определяет его приоритет, то есть определяет, какое сообщение более важное и должно быть отправлено в первую очередь.
Все узлы одновременно, бит за битом, начинают отправлять идентификаторы кадров в шину данных. В это же время все узлы также и считывают каждый новый появившийся бит на шине.
Пока отправляемые биты у всех блоков совпадают, все идет без изменений. Но рано или поздно случается конфликт, когда разные узлы одновременно отправят разные биты. И вот тут самое время вспомнить, что доминантный бит (логический 0) перебивает рецессивный бит (логическую 1) в конфликтных ситуациях. Это реализовано аппаратно в схемотехнике трансивера.
Это условие приводит к тому, что узел, у которого рецессивный бит (логическая единица) проигрывает арбитраж тому узлу, у которого оказался доминантный бит (логический ноль).
Проиграв арбитраж, блок утрачивает доступ к шине и ждет в режиме «только чтение» следующего арбитража. При этом остальные блоки продолжают арбитраж. Но при каждом очередном конфликте один из них отсеивается. И так до тех пор, пока не останется всего один блок, чье сообщение оказалось самым приоритетным и выиграло арбитраж.
Выигравшему блоку принадлежит право отправить сообщение в шину, а потому именно он будет продолжать начатый кадр.
Важным условием успешного битового арбитража является то, что никакие два узла не могут передавать одно и то же поле арбитража. Из этого правила есть одно исключение: если сообщение не содержит данных, то любой узел может передать это сообщение.
Поскольку шина является проводной, а доминирующий бит логически равен 0, следует, что в арбитраже победит сообщение с численно наименьшим Арбитражным полем.
11-bit и 29-bit идентификаторы
11 бит дают возможность использовать только 2048 идентификаторов, то есть 2048 параметров Этого иногда бывает недостаточно. В этом случае используется 29-битый ID. Таким образом, появляется возможность использовать миллионы идентификаторов.
Кадр с расширенным 29-битным идентификатором (CAN 2.0B) идентичен кадру с 11-битным идентификатором (CAN 2.0A), за исключением более длинного идентификатора. Он используется, например, в протоколе J1939 для большегрузных автомобилей.
Что произойдет, если узел будет один на шине и попытается передать сообщение?
Блок, конечно, выиграет арбитраж и с радостью продолжит передачу сообщения. Но когда придет время подтверждения… ни один узел не пошлет доминирующий бит подтверждения ACK (о нем ниже).
Передатчик почувствует ошибку ACK, пошлет флаг ошибки, увеличит свой счетчик ошибок передачи на 8 и начнет повторную передачу. Это произойдет 16 раз. Затем передатчик перейдет в режим пассивной передачи ошибок.
По специальному правилу алгоритма ограничения ошибок, счетчик ошибок передачи не увеличивается, если узел пассивен и ошибка является ошибкой ACK. Таким образом, узел будет продолжать передачу вечно, по крайней мере, до тех пор, пока кто-то не подтвердит сообщение.
RTR. Запрос на удаленную передачу.
Следующий бит Remote Transmission Request (RTR). Это бит запроса. Он определяет какого типа будет сообщение:
- Dataframe, когда вещающий блок сообщает информацию или
- Remote frame, когда передающий блок запрашивает информацию.
Поле Control
Дальше следует поле Control, в котором первый бит ID extension. Если в нем будет логический ноль, то будет использоваться стандартный 11-битный идентификатор, а если логическая единица, то расширенный 29-битный.
Каждый идентификатор это какой-то параметр. Например, обороты двигателя, температура, состояние замка зажигания, угол поворота руля, скорость автомобиля, запрос на включение кондиционера и так далее.
Биты DL3 — DL0 в поле Control используется для определения заранее количества байтов, которые будут передаваться в следующем поле Data. Чтобы не передавать лишние биты и сократить время фрейма, тем самым увеличив скорость передачи данных. По этой же причине по-умолчанию используется 11-битный идентификатор, чтобы без надобности не тратить время на лишние 18 бит.
Поле Data
В поле Data находится самая полезная информация, которую нужно передать. Обороты, скорость, нагрузка и т. п.
Ради передачи этой информации и строится весь фрейм. Это поле может составлять от 1 до 8 байт, то есть от 8 до 64 бит.
CRC. Контрольная сумма
Следующее поле это контрольная сумма CRC (Cyclic Redundancy Check). Представляет собой значение, вычисленное по определенной формуле, на основе битов из предыдущих полей.
То есть все эти биты обрабатываются определенным алгоритмам в блоке-отправителе. Результат этой отработки записывается в поле контрольной суммы кадра.
После этого уже блок-получатель повторно вычисляет контрольную сумму CRC таким же алгоритмом, но уже на базе полученной информации.
Если каждый из битов был распознан правильно, то контрольная сумма у блока-получателя будет такой же, как и у блока-отправителя. В этом случае данные считаются переданными без ошибок.
Если же контрольная сумма не сходится, распознается ошибка передачи данных и полученная информация игнорируется.
ACK. Бит подтверждения
Следующим идет бит подтверждения ACK (Acknowledge). Узел-отправитель выставляет в нем рецессивное состояние, но узел-получатель перебивает его доминантным в случае успешного приема, тем самым подтверждая передачу сообщения.
Отправитель проверяет наличие бита подтверждения и повторно передает сообщение, если подтверждение не было обнаружено.
Наличие бита подтверждения на шине не означает, что любой из предполагаемых адресатов получил сообщение. Единственное, что мы знаем, это то, что один или несколько узлов на шине приняли его правильно.
EOF. Конец кадра
Дальше идут 7 бит поля End of Frame (EOF). Это конец кадра, после которого кадр завершается и шина снова переходит состояние холостого хода.
И так до тех пор, пока один или несколько блоков снова не начнут отправлять сообщения.
Адресация и идентификация сообщений CAN-шины
Стоит еще раз отметить, что в CAN-сообщениях нет явного адреса. Каждый узел принимает весь трафик на шине. Используя аппаратные фильтры и программное обеспечение, он определяет, является ли сообщение «интересным» или нет.
Фактически, в CAN не существует понятия адреса сообщения. Вместо этого, содержимое сообщений идентифицируется по ID, который присутствует в кадре. Считается, что сообщения CAN имеют «адрес содержимого».
Обычный адрес сообщения будет выглядеть так: «Вот сообщение для узла N». Сообщение с адресом содержимого выглядит так: «Вот сообщение, содержащее данные с меткой N». Разница между этими двумя понятиями небольшая, но существенная.
Содержимое поля арбитража, согласно стандарту, используется для определения приоритета сообщения на шине. Все контроллеры CAN также используют все поле арбитража (некоторые используют только часть) в качестве ключа в процессе аппаратной фильтрации.
Стандарт не говорит, что поле арбитража должно использоваться в качестве идентификатора сообщения. Тем не менее это очень распространенное использование.
Что такое CAN FD (Flexible Data Rate CAN)?
С расширением функциональности автомобиля возрастает и нагрузка на CAN-шину. CAN FD (Flexible Data Rate) была разработана как шина CAN «следующего поколения».
Стандартная длина каждого сообщения была увеличена в 8 раз — с 8 до 64 байт, а максимальная скорость передачи данных была аналогично увеличена с 1 Мбит/с до 8 Мбит/с. Одним словом, CAN FD повышает скорость и эффективность. Поэтому она используется в современных автомобилях.
CAN FD обратно совместим и поддерживает протокол CAN 2.0, а также специальные протоколы, такие как SAE J1939.
CAN FD по сути является расширением оригинального стандарта CAN, как указано в ISO 11898-1, и полностью совместим с классическими CAN-шинами.
Отличия CAN FD от обычной CAN-шины
- CAN FD работает одновременно на двух скоростях. Поле арбитража или заголовок кадра передается со стандартной скоростью, например 500 кбит/с. А поле данных передается на скорости в несколько раз выше, вплоть до 8 Мбит/с.
- Размер сообщения увеличен до 64 байт. В обычной CAN-шине — максимум 8 байт.
- Контроллер CAN FD способен принимать обычные CAN сообщения, а стандартный CAN узел не может принимать кадры формата CAN FD.
- Для шины CAN FD нужны специальные микросхемы-трансиверы с повышенным быстродействием.
В настоящее время CAN FD используется в высокопроизводительных автомобилях, но по мере развития ЭБУ и снижения стоимости аппаратного обеспечения CAN FD, это лишь вопрос времени, когда CAN FD появится практически во всех автомобилях.
Будущее шины CAN
В будущем протокол шины CAN будет оставаться актуальным, хотя на него будут влиять основные тенденции:
- Потребность во все более расширяющихся функциях автомобиля.
- Рост облачных вычислений.
- Развитие Интернета вещей (Internet of Things — IoT).
- Развитие самоуправляемых автомобилей (без водителя).
В частности, рост числа подключенных автомобилей V2X и облачных вычислений приведет к быстрому росту автомобильной телематики и IoT CAN-регистраторов.
В свою очередь, перевод сети шины CAN в режим «онлайн» также подвергает автомобили рискам безопасности и может потребовать перехода на новые протоколы CAN, такие, как CAN FD.
Максимальная скорость CAN-шины
Максимальная скорость шины CAN, согласно стандарту, составляет 1 Мбит/с. Тем не менее некоторые CAN-контроллеры могут работать и с более высокими скоростями.
Медленный CAN low speed (ISO 11898-3) может работать на скорости до 125 кбит/с.
Однопроводной CAN может работать со скоростью около 50 кбит/с в стандартном режиме, а в специальном высокоскоростном режиме, используемом, например, для программирования ЭБУ, — до 100 кбит/с.
Максимальная длина кабеля в CAN-шине
При скорости 1 Мбит/с максимальная длина кабеля может составлять около 40 метров. Это связано с тем, что схема арбитража требует, чтобы волновой фронт сигнала успел распространиться до самого удаленного узла и обратно. Другими словами, длина кабеля ограничена скоростью света.
Другие максимальные длины кабелей (значения приблизительны):
- 100 метров при скорости 500 кбит/с;
- 200 метров — при 250 кбит/с;
- 500 метров — при 125 кбит/с;
- 6 километров — при 10 кбит/с.
Если для обеспечения гальванической развязки используются оптопары, максимальная длина шины соответственно уменьшается.
На чтение 21 мин Просмотров 22.8к. Опубликовано 20.10.2022
Обновлено 20.10.2022
Из этой статьи вы узнаете, что такое CAN-шина, почему она появилась. Разберемся с блоками управления в автомобиле и с тем, как они общаются между собой. Расскажем, какие контроллеры соединяются быстрой CAN-шиной, а какие — медленной.
Узнаете, как устроена CAN-шина на физическом и цифровом уровне, из каких данных состоит сообщение, как происходит арбитраж трафика. Какая максимальная длина кабеля и скорость передачи информации, как реализована защита от помех.
Если интересует какой-то конкретный вопрос, пользуйтесь оглавлением.
Что такое CAN-шина?
Автомобиль подобен человеческому организму. Сеть контроллеров (шина CAN) это как нервная система у человека.
В свою очередь, «узлы» или «электронные блоки управления» (ЭБУ) подобны частям тела. Они соединены между собой через CAN-шину.
Шина CAN представляет собой витую пару проводов. С ее помощью все блоки управления в автомобиле соединены в единую информационную сеть.
Причины появления CAN-шины
Когда вы нажимаете выключатель в своем доме, чтобы включить свет, электричество проходит через выключатель к лампам.
Автомобили раньше использовали такое же подключение. С тех пор как в 1915 году Генри Форду пришла идея добавить в свои автомобили фары и электрический сигнал, электричество поступало от аккумулятора через выключатели к фарам и другим устройствам.
К 1960-м годам в каждом автомобиле были тысячи тяжелых проводов.
После нефтяного эмбарго 1970-х годов на автопроизводителей оказывалось все большее давление с целью повышения эффективности использования топлива. Поэтому они начали искать способы уменьшить вес выпускаемых автомобилей.
К началу 1980-х годов в автомобилях было все больше и больше электронных блоков управления. Сначала электронное управление получили самые важные системы, такие как системы управления двигателем, трансмиссией и тормозной системой. Но со временем электронное управление распространилось и на второстепенные либо периферийные системы, такие как климат-контроль, блоки комфорта и прочие.
В скором времени такое положение дел привело к тому, что производители столкнулись тремя проблемами:
Такие компании, как Bosch, искали тип шинной коммуникационной системы, которая могла бы использоваться в качестве системы связи между несколькими ЭБУ и системами автомобиля.
Они искали на рынке, но не могли найти именно то, что было нужно, поэтому они начали разработку «Controller Area Network» в партнерстве с Mercedes-Benz, Intel, а также несколькими университетами Германии.
Краткая история шины CAN
В 1986 году компания Bosch представила стандарт CAN на конгрессе SAE в Детройте. Год спустя корпорация Intel начала поставки первых микросхем контроллеров CAN, и автомобильный мир изменился навсегда.
- До CAN: автомобильные ЭБУ использовали сложную проводку «точка-точка».
- 1986: Компания Bosch разработала протокол CAN.
- 1991: Bosch опубликовала CAN 2.0 (CAN 2.0A: 11 бит, 2.0B: 29 бит).
- 1993: CAN принят в качестве международного стандарта (ISO 11898).
- 2003: ISO 11898 становится серией стандартов.
- 2012: Bosch выпустила CAN FD 1.0 (передачи данных на двух скоростях).
- 2015: Протокол CAN FD стандартизирован (ISO 11898-1).
- 2016: Физический уровень CAN для скоростей передачи данных до 5 Мбит/с стандартизирован в ISO 11898-2.
Теперь, например, достаточно одного датчика температуры, который подключен к блоку управления двигателем. ЭБУ опрашивает датчик температуры для себя и отправляет эту информацию в виде сообщения в информационную шину данных для других блоков.
При таком подходе уменьшается количество проводов, нет дублирования датчиков. Появляется возможность ввода/вывода информации из электронных блоков управления, что позволяет диагностировать сложные системы с множеством электронных блоков управления.
Сегодня CAN является стандартом в автомобилях (легковых, грузовых, автобусах, тракторах, …), кораблях, самолетах, электромобилях и многом другом.
Что такое ЭБУ?
В автомобиле ЭБУ могут быть, например, блок управления двигателем, подушками безопасности, аудиосистемой и т. д.
В современном автомобиле может быть до 70 ЭБУ — и каждый из них может иметь информацию, которой необходимо поделиться с другими участниками сети.
Именно здесь на помощь приходит CAN-шина. Она позволяет каждому блоку управления общаться со всеми другими ЭБУ без сложной специальной проводки.
В частности, блок управления может передавать данные с датчиков по шине CAN. Переданные данные принимаются всеми другими контроллерами в сети CAN, после чего каждый ЭБУ может проверить данные и решить, принимать их или игнорировать.
Физический уровень шины CAN
Физический уровень CAN описан в стандарте ISO 11898 и регламентирует способ передачи данных. В случае с CAN-шиной это два провода витой пары. При этом CAN-шина вполне может работать и по одному проводу, а витая пара прежде всего используется для защиты от помех.
Однопроводная схема
Для того чтобы лучше понять как данные передаются по двухпроводной CAN-шине, давайте сначала рассмотрим как данные передаются по однопроводной схеме, которой, например, является K-линия.
Итак, есть один провод, с его помощью соединены блоки управления. Этот провод внутри блока соединен с 12 вольтами через резистор 5 килоом. Таким образом напряжение на проводе становится по умолчанию 12 В.
Каждый из подключенных блоков может стягивать это напряжение на массу, меняя его с 12 на 0 вольт. Таким образом, получаются прямоугольные импульсы на шине данных. Они могут принимать всего два уровня напряжения — 0 и 12 вольт.
Присвоим низкому уровню в ноль вольт логический ноль, а уровню 12 вольт — логическую единицу. Зададим тактовый сигнал шины, то есть обозначим сколько раз секунду блоки будут опрашивать шину и соответственно сколько времени будет длиться один бит.
То есть наименьшая часть цифровой информации вид может принимать только два значения 0 или 1. Таким образом, мы получили физическую возможность отправлять и принимать двоичные данные между блоками управления.
Витая пара. Как работает CAN high-speed
В CAN-шине тот же принцип, только сигнал считывается как разница между напряжениями проводов CAN-high и CAN-low, которые образуют витую пару.
Чтобы понять, как именно это происходит, давайте рассмотрим как могут меняться уровни напряжения на этих проводах.
По умолчанию на проводе CAN-high, как и на проводе CAN-low, напряжение соответствует величине в 2,5 В. При этом разница напряжений между проводами составляет 0 В. Такое состояние can-шины называется рецессивным (recessive) и интерпретируется как логическая единица.
Существует и второе состояние шины, при котором напряжение на проводе CAN-high будет 3,5 вольт, а на проводе CAN-low — 1,5 В. Разница напряжений между проводами составит 2 вольта. Это состояние называется доминантным (dominant) и соответствует логическому нулю.
Логическая 1 (рецессивное состояние):
- 2,5 вольта на проводе CAN_H;
- 2,5 вольта на проводе CAN_L;
- дифференциальное напряжение 0 вольт.
Логический 0 (доминантное состояние):
- 3,5 вольта на проводе CAN_H;
- 1,5 вольта на проводе CAN_L;
- дифференциальное напряжение 2 вольта.
Так работает высокоскоростная шина CAN high speed. Она описана в стандарте ISO 11898-2.
Работа CAN low speed
Устройство низкоскоростной шины CAN low speed описано в стандарте ISO 11898-3. Для нее уровни напряжения такие.
Логическая 1 (рецессивное состояние):
- 0 вольт на проводе CAN_H;
- 5 вольт на проводе CAN_L;
- дифференциальное напряжение 5 вольт.
Логический 0 (доминантное состояние):
- 3,6 вольта на проводе CAN_H;
- 1,4 вольта на проводе CAN_L;
- дифференциальное напряжение 2,2 вольта.
Защита от помех
Ведь и на одном проводе все работало, так зачем усложнять?
CAN-шиной объединены самые ответственные блоки управления автомобиля. От качества этой связи напрямую зависит безопасность движения. В связи с этим CAN-шине предъявляются высокие требования к надежности и безотказности.
Дело в том, что многие компоненты автомобиля являются источниками электромагнитных помех. Особенно система зажигания.
Использование витой пары позволяет в значительной степени решить эту проблему. Давайте посмотрим, как это происходит.
Представьте себе, что витая пара CAN-шины попадает в зону действия электромагнитной помехи. В медном проводе индуцируется напряжение, которое плюсуется или отнимается от напряжения, уже существующего на этом проводе.
Предположим, что на проводе CAN-high в рецессивном состоянии напряжение было 2,5 В. Помеха увеличила его на 1,1 В. Соответственно мы получили напряжение в 3,6 В, которое могло быть интерпретировано уже как доминантное состояние.
Но CAN-шина устойчива к таким помехам, потому что сигналом является не просто изменение уровня напряжения на одном из проводов, а именно изменение разницы между напряжениями на этих проводах. А разница как раз не изменилась из-за применения витой пары.
Таким образом, на проводе CAN_L напряжение поднимется на те же 1,1 В. А разница напряжений как была 2,5 — 2,5 = 0 В, так и осталась 3,6 — 3,6 = 0 В. Действие помехи на шину в доминантном состоянии аналогично.
Зачем нужен трансивер
Название Transceiver произошло от двух слов receiver (приемник) и transmitter (передатчик). Переводится как приемопередатчик.
Трансиверы обрабатывают дифференциальный сигнал, принимают и передают информацию. Трансивер связывает провода витой пары (CAN_H и CAN_L) с линиями Tx и Rx микропроцессора, который не умеет напрямую работать с CAN-шиной.
По линии Tx микропроцессор отправляет информацию в шину данных, а по линии Rx он считывает информацию.
В трансивере находится схемотехника, которая формирует разные уровни напряжения на проводах CAN_H и CAN_L для доминантного и рецессивного состояния шины.
Трансивер обычно устанавливается внутри электронного блока управления и представляет собой специализированную микросхему.
Оконечные сопротивления
Это еще одна часть физического уровня CAN-шины. Оконечные сопротивления используются для борьбы с отраженным сигналом так называемым эхом.
Отраженный сигнал препятствует нормальной передаче данных. Причем, чем больше будет длина проводов шины и чем выше будет скорость передачи данных, тем значительней будет проявляться этот негативный эффект.
Правильно подобранные конечные нагрузочные сопротивления компенсируют отраженный сигнал. Обычно это два резистора по 120 ом внутри блока управления. Они подключены к противоположным концам шины. Таким образом, сопротивление между проводами can-шины составляет около 60 ом.
У разных автопроизводителей величина оконечных сопротивлений может отличаться.
Где применяется CAN high speed, а где CAN low speed
HS-CAN и LS-CAN отличаются скоростью передачи данных и уровнями рабочих напряжений. Быстрый CAN применяется для связи блоков управления двигателя, автоматической коробки передач, тормозов, рулевого управления, подушек безопасности, полного привода, пневмоподвески и других важных систем, от которых напрямую зависит безопасность движения.
Медленный CAN используется для менее важных систем, таких как климат-контроль, системы комфорта, наружное освещение, электропривод сидений и т. п. в зависимости от комплектации автомобиля.
Особенностью медленного CAN является возможность сохранять работоспособность в однопроводном режиме, если второй провод витой пары поврежден.
Высокоскоростной и низкоскоростной CAN автопроизводители могут называть по-своему, а также пользоваться любой из доступных скоростей передачи данных.
Межсетевой шлюз (CAN gateway)
Часто есть необходимость передавать информацию от блока управления, подключенного к быстрой CAN-шине, к блоку, подключенному к медленной CAN-шине, и наоборот. Например, блоку управления климатом нужно знать температуру двигателя.
Так как напрямую разные CAN-шины не соединить, для этих целей используется межсетевой шлюз (CAN gateway). К нему подключаются шины с разными скоростями. Это могут быть не только CAN-шины, но и другие шины, присутствующие в автомобиле, к примеру, FlexRay или Ethernet.
Часто в CAN gateway хранится информация об автомобиле, VIN номер и комплектация. Именно из него сканеры получают информацию при автоопределении автомобиля.
Сам межсетевой интерфейс может быть выполнен как отдельным блоком, так и встроен в другие блоки. Обычно это приборная панель, электронный замок зажигания или блок управления бортовой сети (Body Control Module — BCM).
Мы разобрались физическим уровнем CAN-шины. Теперь вы знаете, как напряжение на витой паре становится единицами и нолями, как биты передаются от одного блока управления к другому.
Канальный уровень CAN-шины (передача данных)
CAN является широковещательной шиной последовательной передачи данных. То есть данные отправляются по очереди бит за битом и при этом между узлами сети реализован один общий эфир, когда каждый слышит каждого.
Блоки управления, как и диагностический сканер, выступают узлами в сети CAN-шины. Но для того, чтобы все это заработало мало просто подавать в шину единицы и ноли. Нужно определить, какой узел будет говорить, какой слушать, каков будет формат сообщения, кому это сообщение адресовано и как будет подтверждаться правильность приема.
Эту задачу решает канальный уровень (data link layer), описанный в стандарте ISO 11898-1. Каждый узел может отправлять и принимать информацию кадр за кадром.
Существует четыре типа сообщений-кадров:
- Кадр данных (data frame). Передает информацию одному или нескольким узлам-приемникам.
- Кадр удаленного запроса (remote frame). Запрашивает данные у других узлов.
- Кадр ошибки (error frame). Сообщает об ошибках.
- Кадр перегрузки (overload frame). Сообщает о состоянии перегрузки.
Из чего состоит кадр CAN-шины
Рассмотрим структуру самого распространенного кадра Data frame.
SOF. Начало кадра
Первый бит кадра (SOF — Start Of Frame) всегда доминантный логический ноль. Он выводит шину из состояния холостого хода и начинает передачу данных.
Арбитражное поле
Дальше следует арбитражное поле. Оно используется для того, чтобы определить, какой из узлов получит доступ к вещанию по шине. Ведь передача данных последовательная, бит за битом, кадр за кадром. Соответственно узлам приходится ждать своей очереди для отправки сообщения в шину, но при этом слушают шину они постоянно.
Зачем нужен арбитраж CAN-шины
Арбитраж сообщений это процесс, в котором два или более CAN-контроллеров договариваются о том, кто должен использовать шину.
Любой узел может начать передачу данных, когда обнаружит незанятую шину. Это может привести к тому, что два или более контроллеров начнут передачу сообщения почти одновременно.
Нет такого блока, который будет вещать всегда первым. Первым всегда будет передавать информацию тот блок, чьё сообщение имеет наивысший приоритет. И как раз этот спор и решается в арбитражном поле. Разберемся как именно.
Как происходит арбитраж CAN-шины и что такое идентификатор
Представим, что есть три узла, которые одновременно хотят получить доступ к CAN-шине. После бита «Start Of Frame» каждый из этих блоков начинает отправлять биты идентификаторов в шину данных.
Идентификатор присвоен каждому сообщению и определяет его приоритет, то есть определяет, какое сообщение более важное и должно быть отправлено в первую очередь.
Все узлы одновременно, бит за битом, начинают отправлять идентификаторы кадров в шину данных. В это же время все узлы также и считывают каждый новый появившийся бит на шине.
Пока отправляемые биты у всех блоков совпадают, все идет без изменений. Но рано или поздно случается конфликт, когда разные узлы одновременно отправят разные биты. И вот тут самое время вспомнить, что доминантный бит (логический 0) перебивает рецессивный бит (логическую 1) в конфликтных ситуациях. Это реализовано аппаратно в схемотехнике трансивера.
Это условие приводит к тому, что узел, у которого рецессивный бит (логическая единица) проигрывает арбитраж тому узлу, у которого оказался доминантный бит (логический ноль).
Проиграв арбитраж, блок утрачивает доступ к шине и ждет в режиме «только чтение» следующего арбитража. При этом остальные блоки продолжают арбитраж. Но при каждом очередном конфликте один из них отсеивается. И так до тех пор, пока не останется всего один блок, чье сообщение оказалось самым приоритетным и выиграло арбитраж.
Выигравшему блоку принадлежит право отправить сообщение в шину, а потому именно он будет продолжать начатый кадр.
Важным условием успешного битового арбитража является то, что никакие два узла не могут передавать одно и то же поле арбитража. Из этого правила есть одно исключение: если сообщение не содержит данных, то любой узел может передать это сообщение.
Поскольку шина является проводной, а доминирующий бит логически равен 0, следует, что в арбитраже победит сообщение с численно наименьшим Арбитражным полем.
11-bit и 29-bit идентификаторы
11 бит дают возможность использовать только 2048 идентификаторов, то есть 2048 параметров Этого иногда бывает недостаточно. В этом случае используется 29-битый ID. Таким образом, появляется возможность использовать миллионы идентификаторов.
Кадр с расширенным 29-битным идентификатором (CAN 2.0B) идентичен кадру с 11-битным идентификатором (CAN 2.0A), за исключением более длинного идентификатора. Он используется, например, в протоколе J1939 для большегрузных автомобилей.
Что произойдет, если узел будет один на шине и попытается передать сообщение?
Блок, конечно, выиграет арбитраж и с радостью продолжит передачу сообщения. Но когда придет время подтверждения… ни один узел не пошлет доминирующий бит подтверждения ACK (о нем ниже).
Передатчик почувствует ошибку ACK, пошлет флаг ошибки, увеличит свой счетчик ошибок передачи на 8 и начнет повторную передачу. Это произойдет 16 раз. Затем передатчик перейдет в режим пассивной передачи ошибок.
По специальному правилу алгоритма ограничения ошибок, счетчик ошибок передачи не увеличивается, если узел пассивен и ошибка является ошибкой ACK. Таким образом, узел будет продолжать передачу вечно, по крайней мере, до тех пор, пока кто-то не подтвердит сообщение.
RTR. Запрос на удаленную передачу.
Следующий бит Remote Transmission Request (RTR). Это бит запроса. Он определяет какого типа будет сообщение:
- Dataframe, когда вещающий блок сообщает информацию или
- Remote frame, когда передающий блок запрашивает информацию.
Поле Control
Дальше следует поле Control, в котором первый бит ID extension. Если в нем будет логический ноль, то будет использоваться стандартный 11-битный идентификатор, а если логическая единица, то расширенный 29-битный.
Каждый идентификатор это какой-то параметр. Например, обороты двигателя, температура, состояние замка зажигания, угол поворота руля, скорость автомобиля, запрос на включение кондиционера и так далее.
Биты DL3 — DL0 в поле Control используется для определения заранее количества байтов, которые будут передаваться в следующем поле Data. Чтобы не передавать лишние биты и сократить время фрейма, тем самым увеличив скорость передачи данных. По этой же причине по-умолчанию используется 11-битный идентификатор, чтобы без надобности не тратить время на лишние 18 бит.
Поле Data
В поле Data находится самая полезная информация, которую нужно передать. Обороты, скорость, нагрузка и т. п.
Ради передачи этой информации и строится весь фрейм. Это поле может составлять от 1 до 8 байт, то есть от 8 до 64 бит.
CRC. Контрольная сумма
Следующее поле это контрольная сумма CRC (Cyclic Redundancy Check). Представляет собой значение, вычисленное по определенной формуле, на основе битов из предыдущих полей.
То есть все эти биты обрабатываются определенным алгоритмам в блоке-отправителе. Результат этой отработки записывается в поле контрольной суммы кадра.
После этого уже блок-получатель повторно вычисляет контрольную сумму CRC таким же алгоритмом, но уже на базе полученной информации.
Если каждый из битов был распознан правильно, то контрольная сумма у блока-получателя будет такой же, как и у блока-отправителя. В этом случае данные считаются переданными без ошибок.
Если же контрольная сумма не сходится, распознается ошибка передачи данных и полученная информация игнорируется.
ACK. Бит подтверждения
Следующим идет бит подтверждения ACK (Acknowledge). Узел-отправитель выставляет в нем рецессивное состояние, но узел-получатель перебивает его доминантным в случае успешного приема, тем самым подтверждая передачу сообщения.
Отправитель проверяет наличие бита подтверждения и повторно передает сообщение, если подтверждение не было обнаружено.
Наличие бита подтверждения на шине не означает, что любой из предполагаемых адресатов получил сообщение. Единственное, что мы знаем, это то, что один или несколько узлов на шине приняли его правильно.
EOF. Конец кадра
Дальше идут 7 бит поля End of Frame (EOF). Это конец кадра, после которого кадр завершается и шина снова переходит состояние холостого хода.
И так до тех пор, пока один или несколько блоков снова не начнут отправлять сообщения.
Адресация и идентификация сообщений CAN-шины
Стоит еще раз отметить, что в CAN-сообщениях нет явного адреса. Каждый узел принимает весь трафик на шине. Используя аппаратные фильтры и программное обеспечение, он определяет, является ли сообщение «интересным» или нет.
Фактически, в CAN не существует понятия адреса сообщения. Вместо этого, содержимое сообщений идентифицируется по ID, который присутствует в кадре. Считается, что сообщения CAN имеют «адрес содержимого».
Обычный адрес сообщения будет выглядеть так: «Вот сообщение для узла N». Сообщение с адресом содержимого выглядит так: «Вот сообщение, содержащее данные с меткой N». Разница между этими двумя понятиями небольшая, но существенная.
Содержимое поля арбитража, согласно стандарту, используется для определения приоритета сообщения на шине. Все контроллеры CAN также используют все поле арбитража (некоторые используют только часть) в качестве ключа в процессе аппаратной фильтрации.
Стандарт не говорит, что поле арбитража должно использоваться в качестве идентификатора сообщения. Тем не менее это очень распространенное использование.
Что такое CAN FD (Flexible Data Rate CAN)?
С расширением функциональности автомобиля возрастает и нагрузка на CAN-шину. CAN FD (Flexible Data Rate) была разработана как шина CAN «следующего поколения».
Стандартная длина каждого сообщения была увеличена в 8 раз — с 8 до 64 байт, а максимальная скорость передачи данных была аналогично увеличена с 1 Мбит/с до 8 Мбит/с. Одним словом, CAN FD повышает скорость и эффективность. Поэтому она используется в современных автомобилях.
CAN FD обратно совместим и поддерживает протокол CAN 2.0, а также специальные протоколы, такие как SAE J1939.
CAN FD по сути является расширением оригинального стандарта CAN, как указано в ISO 11898-1, и полностью совместим с классическими CAN-шинами.
Отличия CAN FD от обычной CAN-шины
- CAN FD работает одновременно на двух скоростях. Поле арбитража или заголовок кадра передается со стандартной скоростью, например 500 кбит/с. А поле данных передается на скорости в несколько раз выше, вплоть до 8 Мбит/с.
- Размер сообщения увеличен до 64 байт. В обычной CAN-шине — максимум 8 байт.
- Контроллер CAN FD способен принимать обычные CAN сообщения, а стандартный CAN узел не может принимать кадры формата CAN FD.
- Для шины CAN FD нужны специальные микросхемы-трансиверы с повышенным быстродействием.
В настоящее время CAN FD используется в высокопроизводительных автомобилях, но по мере развития ЭБУ и снижения стоимости аппаратного обеспечения CAN FD, это лишь вопрос времени, когда CAN FD появится практически во всех автомобилях.
Будущее шины CAN
В будущем протокол шины CAN будет оставаться актуальным, хотя на него будут влиять основные тенденции:
- Потребность во все более расширяющихся функциях автомобиля.
- Рост облачных вычислений.
- Развитие Интернета вещей (Internet of Things — IoT).
- Развитие самоуправляемых автомобилей (без водителя).
В частности, рост числа подключенных автомобилей V2X и облачных вычислений приведет к быстрому росту автомобильной телематики и IoT CAN-регистраторов.
В свою очередь, перевод сети шины CAN в режим «онлайн» также подвергает автомобили рискам безопасности и может потребовать перехода на новые протоколы CAN, такие, как CAN FD.
Максимальная скорость CAN-шины
Максимальная скорость шины CAN, согласно стандарту, составляет 1 Мбит/с. Тем не менее некоторые CAN-контроллеры могут работать и с более высокими скоростями.
Медленный CAN low speed (ISO 11898-3) может работать на скорости до 125 кбит/с.
Однопроводной CAN может работать со скоростью около 50 кбит/с в стандартном режиме, а в специальном высокоскоростном режиме, используемом, например, для программирования ЭБУ, — до 100 кбит/с.
Максимальная длина кабеля в CAN-шине
При скорости 1 Мбит/с максимальная длина кабеля может составлять около 40 метров. Это связано с тем, что схема арбитража требует, чтобы волновой фронт сигнала успел распространиться до самого удаленного узла и обратно. Другими словами, длина кабеля ограничена скоростью света.
Другие максимальные длины кабелей (значения приблизительны):
- 100 метров при скорости 500 кбит/с;
- 200 метров — при 250 кбит/с;
- 500 метров — при 125 кбит/с;
- 6 километров — при 10 кбит/с.
Если для обеспечения гальванической развязки используются оптопары, максимальная длина шины соответственно уменьшается.