Can протокол для чайников – Controller area network — Википедия

Введение в протокол 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.marathon.ru

Управление автомобилем по CAN / Habr

Введение

Беспилотный автомобиль StarLine на платформе Lexus RX 450h — научно-исследовательский проект, стартовавший в 2018 году. Проект открыт для амбициозных специалистов из Open Source Community. Мы предлагаем всем желающим поучаствовать в процессе разработки на уровне кода, опробовать свои алгоритмы на реальном автомобиле, оснащенном дорогостоящим оборудованием. Для управления автомобилем было решено использовать Apollo, открытый фреймворк. Для работы Apollo нам необходимо было подключить набор модулей. Эти модули помогают программе получать информацию об автомобиле и управлять им по заданным алгоритмам.

К таким модулям относятся:

• модуль позиционирования автомобиля в пространстве с помощью GPS-координат;
• модуль управления рулем, ускорением и торможением авто;
• модуль состояния систем автомобиля: скорость, ускорение, положение руля, нажатие на педали и т.д.;
• модуль получения информации об окружении автомобиля. С этим справятся ультразвуковые датчики, камеры, радары и лидары.

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

Теоретическая часть

Что такое CAN-шина

В современных автомобилях управление всеми системами взяли на себя электронные блоки (Рис. 1.). Электронные блоки — это специализированные компьютеры, каждый из которых имеет все необходимые интерфейсы для интеграции с автомобилем. С помощью цифровых интерфейсов связи, блоки объединяются в сеть для обмена информацией друг с другом. Самые распространенные цифровые интерфейсы в автомобилях — CAN, LIN, FLEXRay. Из них наибольшее распространение получил именно CAN.

CAN (Controller Area Network) шина — это промышленный стандарт сети. В 1986 году этот стандарт разработали в компании Bosch. А первым автомобилем с CAN-шиной стал Mercedes-Benz W140, выпущенный в 1991 году. Стандарт разрабатывался для возможности устройствам общаться друг с другом без хоста. Обмен информацией осуществляется с помощью специальных сообщений, которые состоят из полей ID, длины сообщения и данных. Каждый блок имеет свой набор ID. При этом приоритет на шине имеет сообщение с меньшим ID. Поле данных может нести информацию, например, о состоянии систем и датчиков, команды управления механизмами и т.д.

Рис. 1. Шина CAN автомобиля.

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

Рис. 2. Физическое представление сигнала в CAN шине

Посредством CAN шины можно получать информацию о состоянии различных датчиков и системах автомобиля. Также по CAN можно управлять узлами автомобиля. Именно эти возможности мы и используем для своего проекта.

Мы выбрали Lexus RX, потому что знали, что сможем управлять всеми необходимыми узлами по CAN. Так как самое сложное при исследовании автомобиля — это закрытые протоколы. Поэтому одной из причин выбора именно этой модели авто стало наличие описания части протокола CAN-шины в opensource-проекте Openpilot.

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

Электроусилитель руля

Электроусилитель руля EPS (Electric Power Steering) — система, предназначенная снизить усилие на руль при повороте (Рис. 3). Приставка «электро» говорит о типе системы — электрическая. Управление рулем с этой системой становится комфортным, водитель поворачивает руль в нужном направлении, а электродвигатель помогает довернуть его до необходимого угла.

Электроусилитель устанавливается на рулевой вал автомобиля, части которого соединены между собой торсионным валом. На торсионный вал устанавливается датчик величины крутящего момента (Torque Sensor). При вращении руля происходит скручивание торсионного вала, которое регистрируется датчиком момента. Данные, полученные от датчика момента, датчиков скорости и оборотов коленвала, поступают в электронный блок управления ECU. А ECU, в свою очередь, уже вычисляет необходимое компенсационное усилие и подает команду на электродвигатель усилителя.

Рис. 3. Схематичное изображение системы электроусилителя руля

Видео: cистема LKA рулит автомобилем с помощью системы EPS.

Электронная педаль газа

Дроссельная заслонка — это механизм регулировки количества топливной смеси, которая попадет в двигатель. Чем больше смеси попадет, тем быстрее едет автомобиль.
Электронная педаль газа — это система, которая задействует работу нескольких электронных узлов. Сигнал о положении педали, при ее нажатии, поступает в блок управления двигателем ECM (Engine Control Module). ECM, на основе этого сигнала, рассчитывает необходимое количество топлива, которое нужно подать в двигатель. В зависимости от необходимого количества топлива, ECM регулирует угол открытия дроссельной заслонки.

Рис. 4. Система электронной педали газа.

Видео: Для работы круиз-контроля используется управление электронной педалью газа.

Электронные системы помощи водителю

Мы купили автомобиль, который оборудован множеством цифровых блоков и систем помощи водителю (ADAS). В нашем проекте мы используем LKA, ACC и PCS.

LKA (Lane Keep Assist) — это система удержания в полосе, которая состоит из фронтальной камеры и вычислительного блока. LKA удерживает автомобиль в полосе движения, когда водитель, например, отвлекся. Алгоритмы в вычислительном блоке получают данные от камеры и на их основе принимают решение о состоянии автомобиля на дороге. Система способна понимать, что автомобиль неконтролируемо движется к правой или левой полосе. В таких случаях подается звуковой сигнал для привлечения внимания водителя. При пересечении полосы система сама скорректирует угол поворота колес так, чтобы автомобиль остался в полосе движения. Система должна вмешиваться только в том случае, если осознает, что маневр между полосами движения не был вызван действием водителя.

ACC (Adaptive Cruise Control) — система адаптивного круиз-контроля, который позволяет выставить заданную скорость следования. Автомобиль сам ускоряется и притормаживает для поддержания нужной скорости, при этом водитель может убрать ногу с педалей газа и тормоза. Этот режим удобно использовать при езде по скоростным магистралям и автострадам. Адаптивный круиз контроль способен видеть препятствия впереди автомобиля и притормаживать для избежания столкновения с ними. Если впереди автомобиля едет другое транспортное средство с меньшей скоростью, ACC сбавит скорость и будет следовать за ним. При обнаружении статичного объекта, ACC сбавит скорость до полной остановки. Для обнаружения объектов перед автомобилем такая система использует радар с миллиметровым диапазоном длин волн. Обычно такие радары работают на частоте 24-72 ГГц и способны уверенно видеть объекты на расстоянии до 300 метров. Радар обычно установлен за передним значком на решетке радиатора.

PCS (Pre-Collision System) — система предотвращения столкновения. Система призвана предотвратить столкновение с автомобилем, который движется впереди. При неизбежности столкновения, система минимизирует урон от столкновения. Здесь так же используются радар для оценки расстояния до объекта и фронтальная камера для его распознавания. Фронт PCS прогнозирует вероятность столкновения на основе скорости автомобиля, расстояния до объекта и его скорости. Обычно у системы есть два этапа срабатывания. Первый этап — система звуком и индикацией на приборной панели оповещает об опасности водителя. Второй этап — активируется экстренное торможение с помощью системы ABS, и включаются преднатяжители ремней безопасности.

Практическая часть

Управление рулем

Первое, что захотелось сделать нашей команде, — это научиться рулить. Рулем в автомобиле могут управлять две системы: парковочный ассистент IPAS (Intelligent Park Assist) и LKA.

IPAS позволяет задавать напрямую угол поворота рулевого колеса в градусах. Так как в нашем автомобиле нет данной системы, проверить и освоить рулевое управление таким способом нельзя.

Поэтому мы изучили электрические схемы автомобиля и поняли, какие CAN-шины могут быть полезны. Мы подключили анализатор CAN-шины. Лог содержит файл записей сообщений в шине в хронологической последовательности. Наша задача была найти команды управления электроусилителем руля EPS (Electric Power Steering). Мы сняли лог поворота рулевого колеса из стороны в сторону, в логе смогли найти показания угла поворота и скорость вращения рулевого колеса. Ниже пример изменения данных в шине CAN. Интересующие нас данные выделены маркером.

Поворот руля влево на 360 градусов

Поворот руля вправо на 270 градусов

Следующим этапом мы исследовали систему удержания в полосе. Для этого мы выехали на тихую улицу и записали логи обмена между блоком удержания в полосе и DSU (Driving Support ECU). С помощью анализатора шины CAN нам удалось вычислить сообщения от системы LKA. На рисунке 6 изображена команда управления EPS.

Рис. 5. Команда управления рулем с помощью системы LKA

LKA управляет рулем путем задания значения момента на валу (STEER_TORQUE_CMD) рулевого колеса. Команду принимает модуль EPS. Каждое сообщение содержит в заголовке значение счетчика (COUNTER), которое инкрементируется при каждой отправке. Поле LKA_STATE содержит информацию о состоянии LKA. Для захвата управления необходимо выставлять бит STEER_REQUEST.

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

На графике (Рис. 6.) представлена диаграмма работы LKA. Torque Sensor — значение с датчика момента на торсионном валу. Torque Cmd — команда от LKA для управления рулем. Из картинки видно, как происходит подруливание LKA для удержания автомобиля в полосе. При переходе через ноль меняется направление поворота руля. Т.е. отрицательное значение сигнала говорит о повороте вправо, положительное — влево. Удержание команды в нуле говорит об отсутствии управления со стороны LKA. При вмешательстве водителя, система перестает выдавать управление. О вмешательстве водителя LKA узнает с помощью второго датчика момента на валу со стороны рулевого колеса.

Рис. 6. График работы системы LKA

Нам предстояло проверить работу команды управления рулем. С помощью модуля StarLine Сигма 10 мы подготовили прошивку для проверки управления. StarLine Сигма 10 должен выдавать в CAN-шину команды на поворот руля влево или вправо. На тот момент у нас не было графического интерфейса для управления модулем, поэтому пришлось использовать штатные средства автомобиля. Мы нашли в CAN-шине статус положения рычага круиз-контроля и запрограммировали модуль таким образом, что верхнее положение рычага приводило к повороту руля вправо, нижнее положение — к повороту влево (Рис. 7).

Рис. 7. Первые попытки рулить

На видео видно, что управление осуществляется короткими секциями. Это возникает по нескольким причинам.

Первая из причин — это отсутствие обратной связи. Если расхождение между сигналом Torque Cmd и Torque Sensor превышает определенное значение Δ, система автоматически перестает воспринимать команды (Рис. 8). Мы настроили алгоритм на корректировку выдаваемой команды (Torque CMD) в зависимости от значения момента на валу (Torque Sensor).

Рис. 8. Расхождение сигнала приводит к ошибке работы системы

Следующее ограничение связано с системой защиты встроенной в EPS. Система EPS не позволяет командами от LKA рулить в широком диапазоне. Что вполне логично, т.к. при езде по дороге резкое маневрирование не безопасно. Таким образом, при превышении порогового значения момента на валу, система LKA выдает ошибку и отключается (Рис. 9).

Рис. 9. Превышение порогового значения регулировки момента на валу

Независимо от того, активирована система LKA или нет, сообщения с командами от нее присутствуют в шине постоянно. Мы посылаем модулю EPS команду повернуть колеса с конкретным усилием влево или вправо. А в это время LKA перебивает наши посылки «пустыми» сообщениями. После нашей команды со значением момента, приходит штатная с нулевым (Рис. 10).

Рис. 10. Штатные сообщения приходят с нулевыми значениями момента и перебивают наше управление

Тогда мы, с помощью модуля StarLine Сигма 10, смогли фильтровать весь трафик от LKA и блокировать сообщения с ID 2E4, когда нам это было нужно. Это решило проблему, а нам удалось получить плавное управления рулем (Рис. 11).

Рис. 11. Плавная регулировка поворота руля без ошибок

Управление газом

Система адаптивного круиз-контроля ACC управляет ускорением и торможением программно по CAN-шине. Блок управления двигателем ECU принимает команды DSU, если необходимо ускориться — активирует электронную педаль газа. Для торможения автомобиля используется рекуперативное торможение. При этом на торможение и ускорение используется одна команда, отличаются только значения.

Команда управления ускорением или замедлением представлена на рисунке 12. Она состоит из величины ускорения ACCEL_CMD, пары служебных бит и контрольной сумма Checksum. Для ускорения автомобилем значение ACCEL_CMD положительное, для замедления — отрицательное. Ускорение задается в диапазоне от 0 до 3 м/с^2, замедление аналогично, но со знаком минус. Для отправки данных в шину необходимо пересчитать желаемое ускорение или замедление с коэффициентом 0,001. Например, для ускорения 1 м/с^2, ACCEL_CMD = 1000 (0x03E8).

Рис. 12. Команда управления ускорения/замедления автомобиля

Мы сняли логи со штатной системы ACC и проанализировали команды. Сравнили с имеющимся у нас описанием команд и приступили к тестированию.

Рис. 13. Лог управления ускорением/замедлением системы адаптивного круиз-контроля ACC (выделено маркером)

Здесь не обошлось без трудностей. Мы выехали на дорогу с оживленным трафиком для тестирования команды ускорения. Команды управления ускорением или замедлением автомобиля работают только при активированном круиз контроле, не достаточно активировать его кнопкой. Необходимо найти движущийся впереди автомобиль и включить режим следования за ним.

Рис. 14. Активация круиз контроля происходит при наличии впереди другого траснпортного средства

С помощью модуля StarLine Сигма 10 посылаем команду ускорения, и автомобиль начинает набирать скорость. К этому моменту мы подключили графический интерфейс для управления модулем StarLine Сигма 10. Теперь мы управляем рулем, ускорением и торможением с помощью кнопок в приложении.

Команды работали до тех пор, пока не потеряли автомобиль впереди. Система круиз-контроля отключилась, а следовательно, и команды ускорения перестали работать.
Мы приступили к исследованию возможности использовать команды без активного круиз-контроля. Пришлось много времени потратить на анализ данных в шине CAN, чтобы понять как создать условия для работы команд. Нас интересовало, в первую очередь, какой блок блокирует выполнение команд ACC на ускорение или замедление. Пришлось изучить какие ID идут от DSU, LKA, радара и камеры, подсовывая липовые данные различных датчиков.

Решение пришло спустя 3 недели. К тому времени мы представляли как происходит взаимодействие блоков автомобиля, провели исследование трафика сообщений и выделили группы сообщений, посылаемых каждым блоком. За работу адаптивного круиз-контроля ACC отвечает блок Driving Support ECU (DSU). DSU выдает команды на ускорение и замедление автомобиля, и именно этот блок получает данные от радара миллиметрового диапазона. Радар сообщает DSU на каком расстоянии от машины движется объект, с какой относительной скоростью и определяет его положение по горизонтали (левее, правее или по центру).

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

a) б)
Рис. 15. Активация круиза: a) попытка активировать без подмены данных радара; б) активация при подмене данных от радара.

Когда запускаем нашу обманку, на приборной панели загорается значок наличия впереди идущего автомобиля. Теперь мы можем тестировать наше управление. Запускаем команду на ускорение, и автомобиль начинает быстро ускоряться.

Как мы уже узнали, команда на ускорение и замедление одна. Поэтому тут же проверили и замедление. Поехали на на скорости с активным круиз-контролем, запустили команду на торможение, и авто сразу же замедлилось.

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

Цель достигнута.

Что еще мы используем

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

Оборудование и ПО

Для работ с автомобилем сегодня мы используем набор различного оборудования:

• Анализатор шины Marathon позволяет подключать и читать данные с двух шин одновременно. На сайте производителя анализатора есть бесплатное ПО для анализа логов. Но мы используем ПО, написанное в нашей компании для внутреннего пользования.
• Модуль StarLine Сигма 10 мы используем как платформу для работы с цифровыми интерфейсами. Модуль поддерживает CAN и LIN интерфейсы. При исследовании автомобиля пишем программы на C, зашиваем их в модуль и проверяем работу. Из модуля можем сделать сниффер трафика CAN-шины. Сниффер нам помогает понять, какие ID идут от блока или блокировать сообщения от штатных систем.
• Диагностическое оборудование Toyota/Lexus. С помощью этого оборудования можно найти команды управления системами автомобиля: поворотниками, стоп-сигналами, клаксоном, индикацией приборки.

Сегодня ведется активная работа по разработке беспилотного автомобиля, в ближайших планах реализация экстренного торможения перед препятствиями, их объезда и перестраивание маршрута автомобиля в зависимости от дорожной ситуации и указаний водителя.

Беспилотный автомобиль StarLine — это открытая площадка для объединения лучших инженерных умов России и мира с целью создания прогрессивных технологий беспилотного вождения, которые сделают наше будущее безопасным и комфортным.

GitLab проекта

habr.com

Использование сети CAN и стека CANopen / Habr

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

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

CAN (Controller Area Network) — это стандарт, созданный компанией Bosсh для сетей, используемых в автоматизации и промышленности. Стандарт нашел широкое применение в промышленном производстве, технологиях «умного дома», а так же в автомобилестроении. Очень хорошо подходит для связывания различных датчиков и управляющих устройств в единую сеть.
Как правило, CAN-сеть это сеть типа «шина», в которой все узлы могут передавать и принимать данные.
Она обладает небольшой скоростью, но высокой надежностью.

Далее я хочу поверхностно описать стандарт и рассказать об использовании такой сети на практике.

Стандарт

Стандарт описывает канальный уровень и базовые требования к физическому уровню.
Главное в физическом уровне — это требование возможности передачи бита как “доминантного” и “рецессивного“. Доминантный сигнал считается единицей, а рецессивный — нулем. Основное требование — при передаче доминантного и рецессивного сигнала одновременно, всем узлам должен прийти доминантный сигнал. На этом принципе основан механизм арбитража. Из этого следует, что для передачи могут использоваться разные среды, однако на практике чаще всего используют дифференциальную пару.

Передача в сети происходит кадрами. В стандарте существуют два типа кадров: базовый и расширенный.
Базовый кадр содержит 11 битовый идентификатор, а расширенный — 29 битовый. Кадр так же содержит бит запроса на передачу, информацию о длине передаваемых данных и сами данные. Они могут занимать от 0 до 8 байт в кадре. Так же кадр содержит некоторую служебную информацию, но для программиста она не принципиальна, поскольку её добавление реализовано аппаратно в контроллере сети.
Изначально идентификаторы не привязаны к какому либо узлу и характеризуют именно сообщение, а не отправителя и получателя. Идентификаторы так же показывают приоритетность сообщения. Приоритет определяется доминантными битами в идентификаторе. Так 10000000000 приоритетнее чем 01000000000.

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

Помимо этого используются механизмы обнаружения ошибок, такие как контроль передачи, дополняющие биты, использование контрольной суммы и проверка значений полей. Разработчики оценивают вероятность невыявления ошибки передачи как 4,7×10-11.

Данный стандарт не описывает протоколы верхнего уровня, поэтому было создано несколько реализаций, как коммерческих, так и открытых.
Наиболее известные из них:
— CANopen
— DeviceNet
— CAN Kingdom

Эту и даже более подробную информацию о стандарте легко найти в интернете, поэтому я наконец приступаю к описанию CANopen.

CANopen

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

Основные моменты протокола CANopen:
— протокол работает со стандартными идентификаторами. Сеть может содержать до 127 узлов.
— каждому узлу выдается уникальный номер в сети.
— протокол не требует обязательного наличия мастера сети (однако существуют возможности, которые доступны только одному узлу в сети, который условно можно назвать мастером)
— OD (Object Dictionary ) — словарь объектов. Содержит отсортированный список переменных, доступ к которым можно получить по сети с помощью SDO.
— SDO (Service Data Objects) — механизм доступа к словарю объектов. Для доступа к объектам узла сети на этом узле должен быть запущен так называемый SDO-сервер. В сети может быть только один SDO-клиент, условно называемый мастером, который может получать данные от любого из серверов.
— PDO (Process Data Objects) — объекты для быстрого взаимодействия между узлами. Могут содержать до 8 байт данных и передаются в одном кадре. Для каждого PDO выделяется свой идентификатор (в определенном диапозоне). PDO условно делятся на входящие (RPDO) и исходящие (TPDO). Изначально предполагается, что каждый узел будет иметь по 4 RPDO и 4 TPDO, однако их можно перераспределить между узлами вплоть до того, что один узел будет иметь возможность принимать и передавать до 512 PDO. Однако в этом случае на другие узлы идентификаторов не хватит.
PDO могут посылаться по таймеру, по наступлению определенного события либо по прямому запросу на посылку из управляющей программы.
— NMT (Network Management) — менеджер сети. Сообщения этого типа могут переводить узлы в разные состояния (инициализация, рабочее, предрабочее, остановленное), а так же с их помощью обеспечивается контроль работы сети — механизм heartbeat.
— Heartbeat — переводится как сердцебиение. Суть механизма заключается в том, что каждый узел передает в сеть определенное сообщение, уникальное для каждого узла (ID получается путем прибавления номера узла в сети к определенному числу). Любой узел, который хочет узнать, по прежнему ли ему доступны узлы с определенными id должен просто принимать и обрабатывать эти сообщения. Сообщения от неинтересных для него узлов могут игнорироваться.
— Emergency message — в протоколе предусмотрена посылка сообщений об аварийных ситуациях.
— EDS (Electronic Data Sheets) — специальные текстовые файлы, позволяющие настроить словарь объектов. Существуют программы, помогающие в генерации таких файлов.

CANopenNode

CANopenNode — открытая реализация протокола CANopen, написанная на чистом С для использования в микроконтроллерах.

Теперь я опишу особенности, с которыми мне пришлось столкнуться при работе с CANopenNode.
1. Я использовал 32-битный контроллер, а CANopenNode изначально написан для 8/16 битных. Из-за этого в одном месте таймер сходил с ума, поскольку вместо того, чтобы переполниться и, как следствие, обнулиться, он продолжал расти и в механизме хартбита выдавалась ошибка о том, что поголовно все узлы превысили время ожидания нового хартбита.
2. Моя задача предполагала, что я могу передавать большие объемы данных. При этом несколько контроллеров могли передавать эти данные, а остальные — получать. Пришлось отказаться от механизма SDO (поскольку в нем только один контроллер имел бы возможность посылать данные с размером больше чем 8 байт) и написать свою собтвенную надстройку, которая использовала первые два байта PDO в виде управляющей информации.
3. Решение из пункта два привело к тому, что мне потребовалось однозначно определять участников взаимодействия, что возможно сделать только с помощью идентификаторов.
Это был, пожалуй, самый тонкий момент в работе. Было решено ограничить количество «мастеров» четырьмя штуками. Эти четыре узла получали 127 PDO на вход и на выход. А остальные узлы работали с 4 входящими и исходящими PDO. При чем, идентификаторы PDO были распределены так, что узлы-«ведомые» имели по одному исходящему сообщению, каждое из которых читал только определенный «мастер» и по одному входящему сообщению от каждого «мастера». Мастера же соответственно имели по одному каналу для обращения лично к любому из «ведомых» и точно знали, кто из них обращается к нему.
Эта концепция была сложнее всего, так как даже на форумах, где люди работают с CAN, бытует мнение, будто CANopen нельзя настроить подобным образом.
4. Настройка идентификаторов в данном протоколе происходит в коде. Более того, от неё зависят id узлов, которые будет читать и принимать конкретный узел. Поэтому смена id на ходу представляется сложной для данного протокола и требует дополнительных усилий.

В виде заключения

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

Я с удовольствием отвечу на любые вопросы, принимаю критику и дополнения, а так же могу подробнее остановиться на каких-либо моментах, если кому-нибудь это будет интересно.
Спасибо Вам за внимание!

Ссылки на некоторые ресурсы, связанные с CAN

www.can-cia.org — (англ.) международная организация CAN in Automation.
sourceforge.net/projects/canopennode — (англ.) проект CANopenNode

UPD:
Забыл добавить еще один интересный момент, который некоторое время вводил меня в заблуждение. Я отлаживал свою сеть на двух контроллерах, которые я соединил напрямую.
1. Когда я перепрошивал один из контроллеров, сеть на втором начинала выдавать ошибки (начинали часто-часто мигать лампочки — поведение, определенное в стеке CANopen). При обычной перезагрузке контроллера такого не происходило. Возможно, это специфика конкретного контроллера, но на всякий случай это стоит иметь в виду.
2. Протокол CANopen спроектирован таким образом, что если сообщение с определенным id не было отправлено до того момента, как оно должно быть отправлено еще раз, то это тоже вызывает ошибку. При том, каждый узел сети каждую секунду посылает хартбит-сообщение. Поэтому даже если вы ничего не отправляете, то всё равно можете получить ошибку сети.

habr.com

Последовательная шина передачи данных CAN. Введение.

Необходимость последовательного соединения в автомобилях

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

Предыдущую читайте здесь.

Многие автомобили уже имеют большое количество электронных систем управления. Рост автомобильной электроники является результатом отчасти стремления потребителя к большей безопасности и комфорту, а также отчасти требований правительства по улучшению контроля за выбросами и снижению расхода топлива. Управляющие устройства, отвечающие этим требованиям уже используются в течение некоторого времени в области управления двигателем, коробкой передач и дроссельной заслонкой, а также в антиблокировочных системах (ABS) и системе управления ускорением (ASC) .

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

Кроме того, разрабатывается ряд систем, реализующих функции, охватывающие более одного управляющего устройства. Например, ASC требует взаимодействия системы управления двигателем и управления дросселем (впрыском) для уменьшения крутящего момента при проскальзывании ведущего колеса. Другим примером функций, охватывающих более одного блока управления, является электронное управление коробкой передач, где легкость переключения передач может быть улучшена путем кратковременной регулировки опережения зажигания.

Если мы также рассмотрим будущие разработки, направленные на общую оптимизацию транспортных средств, то необходимо преодолеть ограничения, существующие в связи с обычными устройствами управления. Это можно сделать только путем объединения в сеть компонентов системы с использованием последовательной шины данных. Bosch разработал для этой цели систему «Controller Area Network» (CAN), которая с тех пор была стандартизирована на международном уровне (ISO 11898) и была «отлита в камне (в кремнии)» несколькими производителями полупроводников.

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

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

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

Использование CAN сети в автомобилях

Существует четыре основных приложения для последовательной связи в транспортных средствах, каждое из которых имеет разные требования и цели.

• Сетевые контроллеры для синхронизации двигателя, трансмиссии, шасси и тормозов. Скорости передачи данных находятся в диапазоне – типичном для систем реального времени от 200 кбит /с до 1 Мбит /с. • Сетевые компоненты общей электроники и электроники шасси, которые делают автомобиль более комфортным. Примерами таких мультиплексных применений являются управление освещением, кондиционирование воздуха и центральный замок, а также регулировка сиденья и зеркала. Особое значение здесь должно быть уделено стоимости компонентов и требованиям к проводке. Типичная скорость передачи данных составляет около 50 кбит / с. • В ближайшем будущем последовательная связь также будет использоваться в области мобильной связи, чтобы связать такие компоненты, как автомобильные радиоприемники, автомобильные телефоны, навигационные средства и т. д., с центральной более эргономичной панелью управления. Функции, определенные в проекте «Прометей», такие как связь между транспортным средством и транспортным средством, будут в большой степени зависеть от последовательной связи. • В настоящее время CAN используется для первых трех приложений, но для диагностики предпочтительным решением является интерфейс в соответствии со стандартом ISO 9141.

Промышленные применения сети CAN

Сравнение требований к шинным системам транспортных средств и системам промышленных полевых шин показывает удивительные сходства: низкая стоимость, работоспособность в жесткой электрической среде, высокие возможности в реальном времени и простота использования одинаково желательны в обоих секторах.

Стандартное использование CAN в «S-классе» Mercedes-Benz и принятие CAN коммерческими автопроизводителями США для быстрой передачи (до 1 Мбит / с) заставляли промышленных пользователей навострить уши. Не только производители мобильных и стационарных сельскохозяйственных и морских машин и оборудования выбрали CAN, но и выбор производителей медицинской аппаратуры, текстильных машин, а также специальной техники и элементов управления лифтами. Система последовательной шины особенно хорошо подходит для сетевых «интеллектуальных» устройств ввода-вывода, а также датчиков и исполнительных механизмов внутри машины или завода.

Промышленность текстильного машиностроения является одним из пионеров CAN. Один производитель оснастил свои ткацкие станки модульными системами управления, сообщающимися в режиме реального времени через сети CAN еще в 1990 году. Тем временем несколько производителей текстильных машин объединились в группу «CAN Textile Users Group», которая, в свою очередь, является членом международной группы пользователей и производителей «CAN in Automation». Аналогичные требования к текстильному оборудованию имеются в упаковочных машинах и машинах для производства и обработки бумаги.

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

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

Как функционируют CAN-сети

Принципы обмена данными

Когда данные передаются по CAN, никакие станции не адресуются, но вместо этого содержание сообщения (например, скорость вращения или температура двигателя) обозначается идентификатором, который является уникальным во всей сети. Идентификатор определяет не только содержимое, но и приоритет сообщения. Это важно для распределения шины, когда несколько станций конкурируют за доступ к шине. Если ЦПУ данной станции желает отправить сообщение одной или нескольким станциям, он передает данные и их идентификаторы в назначенный CAN-чип (стостояние «Готово»). Это все, что должен сделать ЦП, чтобы инициировать обмен данными. Сообщение формируется и передается с помощью CAN-чипа. Как только CAN-чип получает выделение шины (состояние «Send Message»), все остальные станции в сети CAN становятся получателями этого сообщения (состояние «Receive Message»). Каждая станция в сети CAN, правильно приняв сообщение, выполняет приемный тест (тест получения), чтобы определить, относятся ли полученные данные к этой станции (состояние «Выбор»). Если данные имеют значение для соответствующей станции, они обрабатываются (состояние «Принято»), в противном случае они игнорируются. Высокая степень гибкости системы и конфигурации достигается благодаря схеме адресации, ориентированной на содержание. Очень просто добавлять станции в существующую сеть CAN без внесения каких-либо изменений в аппаратные или программные средства для существующих станций при условии, что новые станции являются чисто приемниками. Поскольку протокол передачи данных не требует физических адресов назначения для отдельных компонентов, он поддерживает концепцию модульной электроники, а также допускает множественный прием (широковещательный, многоадресный) и синхронизацию распределенных процессов: могут быть переданы измерения, необходимые в качестве информации несколькими контроллерами через сеть таким образом, что для каждого контроллера не требуется иметь свой собственный датчик.

1. Передача вещания и входная фильтрация узлами CAN на предмет того подходящие ли данные для того или иного узла

Неразрушающая побитовая проверка:

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

2. Принцип неразрушающего побитового проверки(оценки, считывания)

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

Конфликты доступа к шине разрешаются путем побитной проверки каждой из участвующих станций получаемых идентификаторов через наблюдение (считывание) уровня шины бит за битом. В соответствии с «проводным и» механизмом, посредством которого доминирующее состояние (логический 0) перезаписывает рецессивное состояние (логический 1), конкуренция за распределение шины теряется всеми этими станциями с рецессивной передачей и доминирующим наблюдением (ожиданием 0 для получения). Все «проигравшие» автоматически становятся получателями сообщения с наивысшим приоритетом и не передают повторную передачу до тех пор, пока шина не будет доступна снова.

Эффективность распределения шины: 

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

• Распределение по фиксированному графику. Распределение производится последовательно каждому участнику для максимальной продолжительности независимо от того, нужена ли этому участнику шина в данный момент или нет (примеры: маркерная ячейка или передача маркера). • Распределение шины на основе необходимости. Шина назначается одному участнику на основании невыполненных запросов на передачу, то есть система распределения учитывает только участников, желающих передать (примеры: CSMA, CSMA / CD, управляющий полет, циклическая или побитовая проверка). Для CAN распределение шины согласовано исключительно между сообщениями, ожидающими передачи. Это означает, что процедура, определенная CAN, классифицируется как распределение на основе необходимости.

Еще одним средством оценки эффективности систем проверки(оценки) шины является метод доступа к шине:

• Неразрушающий доступ к шине. С помощью методов этого типа шина назначается одной и только одной станции либо немедленно, либо в течение определенного времени после одного доступа к шине (одной или несколькими станциями). Это гарантирует, что каждый доступ к шине одной или несколькими станциями приводит к однозначному распределению шины (примеры: : маркерная ячейка, передача маркера, циклическая обработка, побитовая проверка. • Разрушающее распределение шины. Одновременный доступ к шине более чем одной станцией приводит к прерыванию всех попыток передачи и, следовательно, успешное распределение шины отсутствует. Для распределения шины может потребоваться более одного доступа к шине, количество попыток до успешного распределения шины является чисто статистической величиной (примеры: CSMA / CD, Ethernet). Чтобы обрабатывать все запросы на передачу сети CAN, соблюдая ограничения времени ожидания при как можно более низкой скорости передачи данных, CAN-протокол должен реализовывать метод распределения шины, который гарантирует, что всегда имеется однозначное распределение шины, даже если есть одновременныё доступ к шине с разных станций.

Метод поразрядной проверки с использованием идентификатора сообщений, которые должны передаваться, однозначно разрешает любое столкновение между несколькими станциями, которые хотят передавать, и он делает это самое позднее в течение 13 (стандартного формата) или 33 (расширенного формата) битовых периодов для любого периода доступа к шине. В отличие от проверки по сообщениям, используемого методом CSMA / CD, этот неразрушающий метод разрешения конфликтов гарантирует, что пропускная способность шины не используется без передачи полезной информации.

Даже в ситуациях, когда шина перегружена, связь приоритета доступа к шине с содержимым сообщения оказывается полезным атрибутом системы по сравнению с существующими протоколами CSMA / CD или токенными(маркерными) протоколами: несмотря на недостаточную пропускную способность шины, все невыполненные запросы на передачу обрабатываются в порядке их важности для всей системы (как определено приоритетом сообщения).

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

Неразрушающий доступ к шине можно разделить на:

• Централизованное управление доступом к шине и • Децентрализованное управление доступом к шине

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

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

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

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

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

3. Кадр сообщения для стандартного формата (CAN Specification 2.0A)

Форматы сообщений.

Протокол CAN поддерживает два формата фреймов (кадров) сообщения, единственное существенное отличие заключается в длине идентификатора (ID). В стандартном формате длина идентификатора равна 11 битам, а в расширенном формате длина равна 29 битам. Кадр сообщения для передачи по шине содержит семь основных полей.

Сообщение в стандартном формате начинается с стартового бита «начало кадра», за ним следует «поле проверки», которое содержит идентификатор и бит «RTR» (запрос удаленной передачи), который указывает, является ли это кадр с данными или кадр запроса без каких-либо байтов данных (кадр удаленного запроса).

«Поле управления» содержит бит расширения IDE (идентификатор расширения), который указывает либо стандартный формат, либо расширенный формат, бит зарезервирован для будущих расширений и – в последних 4 битах – счет байтов данных в поле данных.

«Поле данных» находится в диапазоне от 0 до 8 байтов в длину и сопровождается полем «CRC», которое используется в качестве проверки безопасности кадра для обнаружения битовых ошибок.

Поле «ACK» содержит слот ACK (1 бит) и разделитель ACK (один рецессивный бит). Бит в слоте ACK отправляется как рецессивный бит и перезаписывается в качестве доминантного бита теми приемниками, которые на этот момент времени приема данных приняли их корректно(правильно) (положительное подтверждение). Правильные сообщения подтверждаются приемниками независимо от результата приемочной проверки. Конец сообщения обозначается «конец кадра». «Перерыв» – это минимальное количество периодов битов, разделяющих последовательные сообщения. Если какой-либо станции нет следующего доступа к шине, шина остается бездействующей («bus idle»).

Обнаружение и сигнализация об ошибках.

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

• Циклическая проверка избыточности (CRC) CRC защищает информацию в кадре путем добавления избыточных проверочных битов на конце передачи. На конце приемника эти биты повторно вычисляются и проверяются на соответствие принятым битам. Если они не согласны, произошла ошибка CRC. • Проверка кадра – этот механизм проверяет структуру передаваемого кадра, проверяя битовые поля на фиксированный формат и размер фрейма. Ошибки, обнаруженные при проверке кадров, обозначаются как «ошибки формата». • Ошибки ACK. Как уже упоминалось выше, полученные кадры подтверждаются всеми получателями посредством «положительного подтверждения». Если не получено подтверждение передатчиком сообщения (ошибка ACK), это может означать, что есть ошибка передачи, которая была обнаружена только получателями, что поле ACK было повреждено или что нет приемников.

Протокол CAN также реализует два механизма обнаружения ошибок на уровне битов.

• Мониторинг. Способность передатчика обнаруживать ошибки основана на контроле сигналов шины: каждый узел, который передает, также наблюдает за уровнем шины и, таким образом, обнаруживает различия между отправленным битом и полученным битом. Это обеспечивает надежное обнаружение всех глобальных ошибок и ошибок, локальных для передатчика. • Набивка бит – кодирование отдельных битов проверяется на уровне битов. Битовое представление, используемое CAN, – это кодирование NRZ (non-return-to-zero), которое гарантирует максимальную эффективность в кодировании битов. Края синхронизации генерируются посредством заполнения битов, то есть после пяти последовательных равных битов отправитель вставляет в поток битов бит информации с дополнительным значением, которое удаляется приемниками. Проверка кода ограничивается проверкой соблюдения правила заполнения. Если одна или несколько ошибок обнаруживаются по меньшей мере одной станцией (любой станцией) с использованием указанных выше механизмов, текущая передача прерывается отправкой «флага ошибки». Это предотвращает прием другими станциями сообщений и, таким образом, обеспечивает согласованность данных на протяжении всей сети.

После прекращения передачи ошибочного сообщения отправитель автоматически повторяет попытку передачи (автоматический запрос повторения). Может снова возникнуть конкуренция за распределение шины. Как правило, повторная передача начинается в течение 23-битных периодов после обнаружения ошибки; В особых случаях время восстановления системы составляет 31 бит.

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

Надежность данных протокола CAN:

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

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

4. Вероятность остаточной ошибки как функция вероятности ошибки бита

Вычисление вероятности остаточной ошибки требует классификации ошибок и того, что весь путь передачи описывается моделью. Если мы определим вероятность остаточной ошибки CAN как функцию вероятности ошибки в битах для длин сообщений от 80 до 90 бит, для системных конфигураций, например, пяти или десяти узлов и с частотой ошибок 1/1000 (ошибка в одном сообщении из каждой тысячи), то максимальная вероятность ошибки в битах составляет приблизительно от 0,02 – до порядка 10^-13. Исходя из этого, можно рассчитать максимальное количество необнаруживаемых ошибок для данной сети CAN.

Например, если сеть CAN работает со скоростью передачи данных 1 Мбит/с, при среднем использовании пропускной способности шины 50%, при общем сроке службы 4000 часов и при средней длине сообщения 80 бит, то общее число Передаваемых сообщений составляет 9×10^10. Статистическое число необнаруженных ошибок передачи в течение срока эксплуатации, таким образом, составляет менее чем порядка 10^-2. Или, иначе говоря, с продолжительностью работы восемь часов в день на 365 дней в году и частотой ошибок каждые 0,7 с, одна необнаруженная ошибка происходит раз в тысячу лет (статистическое среднее значение).

Сообщения CAN расширенного формата

Подкомитет SAE «Грузовые автомобили и автобусы» стандартизовал сигналы и сообщения, а также протоколы передачи данных для различных скоростей передачи данных. Стало очевидно, что стандартизацию такого рода легче реализовать, когда доступно более длинное поле идентификации.

Чтобы поддержать эти усилия, протокол CAN был расширен за счет введения 29-битного идентификатора. Этот идентификатор состоит из существующего 11-битного идентификатора (базового ID) и 18-битного расширения (ID-расширения). Таким образом, протокол CAN позволяет использовать два формата сообщений: StandardCAN (Версия 2.0A) и ExtendedCAN (Версия 2.0B). Поскольку два формата должны сосуществовать на одной шине, устанавливается, какое сообщение имеет более высокий приоритет на шине в случае коллизий доступа к шине с форматами сглаживания и одним и тем же базовым идентификатором: стандартное сообщение всегда имеет приоритет над сообщением в расширенном формате.

CAN-контроллеры, которые поддерживают сообщения в расширенном формате, могут также отправлять и получать сообщения в стандартном формате. Только сообщения в стандартном формате могут передаваться по всей сети, если в этой сети используются CAN-контроллеры, которые поддерживают только стандартный формат (Версия 2.0A). Сообщения в расширенном формате будут неправильно поняты. Однако есть CAN-контроллеры, которые поддерживают только стандартный формат, но распознают сообщения в расширенном формате и игнорируют их (версия 2.0B пассивная).

Различие между стандартным форматом и расширенным форматом осуществляется с использованием бита IDE (бит расширения идентификатора), который передается как доминирующий в случае кадра в стандартном формате. Для кадров в расширенном формате это рецессивно. Бит RTR передается доминантно или рецессивно в зависимости от того, передаются ли данные или запрашивается конкретное сообщение от станции. Вместо бита RTR в стандартном формате бит SRR (замена удаленного запроса) передается для кадров с расширенным идентификатором. Бит SRR всегда передается как рецессивный, чтобы гарантировать, что в случае проверки стандартный кадр всегда имел приоритетное распределение шины к расширенному кадру, когда оба сообщения имеют одинаковый базовый идентификатор.

В отличие от стандартного формата, в расширенном формате за битом IDE следует 18-битный ID-номер, бит RTR и зарезервированный бит (r1).

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

5. Кадр сообщения для расширенного формата (CAN Specification 2.0A)

Реализации протокола CAN

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

CAN-контроллер с промежуточным буфером

Контроллеры CAN с промежуточным буфером (ранее называемые чипами basicCAN) реализовали в качестве аппаратного обеспечения логику, необходимую для создания и проверки потока битов согласно протоколу. Однако администрирование наборов данных, которые должны быть отправлены и получены, в частности, фильтрация приёма осуществляется только CAN-контроллером.

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

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

CAN-контроллер с хранилищем объектов.

Объекты CAN состоят в основном из трех компонентов: идентификатора, кода длины данных и фактических полезных данных.

CAN-контроллеры с хранилищем объектов (ранее называемые fullCAN) функционируют как CAN-контроллеры с промежуточными буферами, но также управляют определенными объектами. Там, где есть несколько одновременных запросов, они определяют, например, какой объект должен быть передан первым. Они также выполняют фильтрацию принятия для входящих объектов. Интерфейс к следующему микроконтроллеру соответствует ОЗУ. Данные, подлежащие передаче, записываются в соответствующую область ОЗУ, полученные данные считываются из области ОЗУ, соответственно. Микроконтроллер должен управлять только несколькими битами (например, запросом передачи).

Контроллеры CAN с хранилищем объектов рассчитаны на максимальную нагрузку от локального микроконтроллера. Однако эти CAN-контроллеры требуют большей площади кристалла и, следовательно, более дороги. В дополнение к этому, они могут администрировать только ограниченное количество чипов(микроконтроллеров).

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

CAN подчиненные контроллеры для функций ввода / вывода.

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

Физическое соединение CAN

Скорости передачи данных (до 1 Мбит / с) требуют достаточно крутого наклона импульса, который может быть реализован только с использованием силовых элементов. В принципе возможно несколько физических соединений. Тем не менее, пользователи и производители группы «CAN in Automation» рекомендуют использовать схемы драйверов в соответствии с ISO 11898.

Встроенные микросхемы драйверов в соответствии с ISO 11898 доступны от нескольких компаний (Bosch, Philips, Siliconix и Texas Instruments). Международная группа пользователей и производителей (CiA) также определяет несколько механических соединений (кабель и разъемы).

6. Physical CAN Connection according to ISO 11898

С уважением, перевод предоставлен коллективом мастерской Works-Garage.

Works-Project.ru

www.beworks.ru

Интерфейсы микроконтроллеров (Часть 2) — DRIVE2

начало — www.drive2.ru/b/2602560/
Двухпроводной последовательный интерфейс TWI / I2C

Двухпроводной последовательный интерфейс TWI (Two-wire Serial Interface) является полным аналогом базовой версии интерфейса I2C (двухпроводная двунаправленная шина) фирмы Philips. Этот интерфейс позволяет объединить вместе до 128 различных устройств с помощью двунаправленной шины, состоящей из линии тактового сигнала (SCL) и линии данных (SDA).
Двухпроводной интерфейс (TWI) — двунаправленная двухпроводная последовательная шина передачи данных, совместимая со стандартными шинами I2C и SMBus.
Устройство, подключенное к шине, должно быть либо ведущим, либо подчиненным. Ведущее устройство инициирует передачу данных путем передачи адреса подчиненного устройства и типа передачи: чтение или запись. Если к шине подключено несколько ведущих устройств и некоторая их часть одновременно инициировала передачу, применяется механизм арбитража, который учитывает приоритет этих устройств.
Модуль TWI микроконтроллеров может работать и в роли ведущего, и в роли подчиненного устройства. Ведущая и подчиненная работа полностью отделены друг от друга и предусматривают отдельное управление включением/отключением. Для этих функций также предусмотрены отдельные регистры управления и статуса, а также векторы прерываний. Потеря арбитража, ошибки, коллизии и удержание линии синхронизации обнаруживаются на аппаратном уровне и индицируются отдельными флагами статуса для ведущего и подчиненного режимов.
Ведущий модуль содержит программируемый генератор скорости связи. Даже при синхронизации системы низкими частотами, поддерживается возможность работы шины на частоте 100 и 400 кГц. При необходимости автоматического выполнения операций и снижения сложности программы могут быть разрешены команды QUICK и режим SMART.
В подчиненном модуле на аппаратном уровне реализована возможность распознавания 7-битного адреса и адреса общего вызова. Также поддерживается 10-битная адресация. Предусмотренный регистр маски адреса может выступать в роли второго регистра сравнения, если требуется обнаружение двух подчиненных адресов, или регистра маски, если требуется обнаружение адресов, принадлежащих заданному диапазону.
Логика подчиненного модуля продолжает работать во всех экономичных режимах работы МК, в т.ч. POWER DOWN. Благодаря этому, подчиненный модуль способен возобновить активную работу МК при обнаружении совпадения адреса. При необходимости программного слежения за адресами, аппаратную функцию обнаружения совпадения адреса можно отключить. Потребность в этом может возникнуть, когда необходимо обнаруживать несколько различных адресов и реагировать на них. При необходимости автоматического выполнения действий и снижения сложности программы можно задействовать режим SMART.
Модуль TWI содержит логику контроля состояния шины, которая накапливает информацию для обнаружения условий START и STOP, коллизий и ошибок шины. С её помощью можно определить состояние шины в ведущем режиме (IDLE, OWNER, BUSY или UNKNOWN).
При необходимости подключения к внешнему драйверу шины по 4-проводному интерфейсу, внутренние драйверы модуля TWI можно отключить.

Принцип действия шины TWI

Двухпроводной интерфейс (TWI) подключается к простой двухпроводной и двунаправленной шине, которая состоит из двух линий: линия синхронизации (SCL) и линия последовательной передачи данных (SDA). Источниками сигналов для обеих линий являю

www.drive2.ru

Введение в протокол CAN. CAN-шина не только для автомобилей. Введение в CAN

Администратор

Необходимость последовательного соединения в автомобилях

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

Многие автомобили уже имеют большое количество электронных систем управления. Рост автомобильной электроники является результатом отчасти стремления потребителя к большей безопасности и комфорту, а также отчасти требований правительства по улучшению контроля за выбросами и снижению расхода топлива. Управляющие устройства, отвечающие этим требованиям уже используются в течение некоторого времени в области управления двигателем, коробкой передач и дроссельной заслонкой, а также в антиблокировочных системах (ABS) и системе управления ускорением (ASC) .

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

Кроме того, разрабатывается ряд систем, реализующих функции, охватывающие более одного управляющего устройства. Например, ASC требует взаимодействия системы управления двигателем и управления дросселем (впрыском) для уменьшения крутящего момента при проскальзывании ведущего колеса. Другим примером функций, охватывающих более одного блока управления, является электронное управление коробкой передач, где легкость переключения передач может быть улучшена путем кратковременной регулировки опережения зажигания.

Если мы также рассмотрим будущие разработки, направленные на общую оптимизацию транспортных средств, то необходимо преодолеть ограничения, существующие в связи с обычными устройствами управления. Это можно сделать только путем объединения в сеть компонентов системы с использованием последовательной шины данных. Bosch разработал для этой цели систему «Controller Area Network» (CAN), которая с тех пор была стандартизирована на международном уровне (ISO 11898) и была «отлита в камне (в кремнии)» несколькими производителями полупроводников.

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

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

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

Использование CAN сети в автомобилях

Существует четыре основных приложения для последовательной связи в транспортных средствах, каждое из которых имеет разные требования и цели.

Сетевые контроллеры для синхронизации двигателя, трансмиссии, шасси и тормозов. Скорости передачи данных находятся в диапазоне – типичном для систем реального времени от 200 кбит /с до 1 Мбит /с.
Сетевые компоненты общей электроники и электроники шасси, которые делают автомобиль более комфортным. Примерами таких мультиплексных применений являются управление освещением, ко

crabo.ru

Краткий обзор протокола CAN. Часть II

Вернуться к статьям

По материалам компании Kvaser

Продолжение статьи I части.

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

Содержание статьи

• Шина CAN – Введение.

• Сообщения CAN.

• Физические уровни CAN.

• Разъемы CAN.

• Тактовая синхронизация CAN.

• Обработка ошибок CAN.

Разъемы CAN

Для разъемов CAN стандартов не существует! Обычно, каждый (!) протокол более высокого уровня (Higher Layer Protocol) описывает один или несколько предпочтительных типов разъемов. Основные типы:

• 9–контактный DSUB, предложен CiA;

• 5–контактный Mini–C и/или Micro–C, используется DeviceNet и SDS;

• 6–контактный Deutsch разъем, предложенный CANHUG для транспортных гидравлических систем.

Разъемы CAN

Данное назначение контактов разъема рекомендовано CiA и фактически является промышленным стандартом.

1	-	Резерв
2	CAN_L	Линия шины CAN_L (доминантная низкая)
3	CAN_GND	Заземление CAN
4	-	Резерв
5	(CAN_SHLD)	Опционально: экран CAN
6	(GND)	Опционально: заземление CAN
7	CAN_H	Линия шины CAN_H (доминантная высокая)
8	-	Резерв (линия ошибок)
9	CAN_V+	Опционально: питание

Для пользователей продукции KVASER: Пожалуйста заметьте, что специфическое употребление этих контактов в кабелях KVASER DRVcan описано в документе LAPcan Hardware Guide, который можно скачать на сайте компании.

Если питание подается, оно должно быть в диапазоне +7..+13 В, 100 мA. Модули оснащены разъемом типа «папа» и должны соединять внутри контакты 3 и 6. 

Нумерация контактов действительна для разъема типа «папа„, при взгляде со стороны разъема, или для разъема типа “мама», при взгляде со стороны распайки. – Чтобы запомнить расположение контактов, заметьте, что контакт CAN_LOW имеет МЕНЬШИЙ (LOW) номер, а CAN_HIGH – БОЛЬШИЙ (HIGH).

5-контактный Mini–C

Используется как DeviceNet , так и SDS , и является совместимым для этих двух протоколов.

Контакт	Функция	Цвет DeviceNet
1	Экран	Неизолированный
2	V+	Красный
3	V-	Черный
4	CAN_H	Белый
5	CAN_L	Синий

 

Модули оснащены разъемами типа «папа». Подаваемое напряжение 24 В ±1%

6-контактный Deutsch DT04-6P

Рекомендован CANHUG для использования в транспортных гидравлических системах

Разъемы на модулях типа «папа», разъемы шины – «мама». На данный момент нет никаких рекомендаций по вопросу подачи питания.

 

Контакт	Функция	Рекомендованный цвет кабеля
1	«Минус» питания	Черный
2	CAN_H	Белый
3	Опционально: заземление сигнала	Желтый
4	Опционально: запуск	Серый
5	«Плюс» питания	Красный
6	CAN_L	Синий

Тактовая синхронизация CAN

Схема бита

Каждый бит, передаваемый по шине CAN, разделяется, для нужд тактовой синхронизации, как минимум на 4 части (кванта). Часть логически делится на 4 группы или сегмента:

• сегмент синхронизации

• сегмент воспроизведения

• сегмент фазы 1

• сегмент фазы 2

Схема бита данных шины CAN:

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

Сегмент воспроизведения нужен для компенсации задержки на линиях шины.

Сегменты фазы могут быть сокращены (сегмент фазы 1) или удлинены (сегмент фазы 2), если это потребуется для сохранения синхронизованности тактовых частот.

Уровни шины замеряются на границе между сегментом фазы 1 и сегментом фазы 2.

Большинство контроллеров CAN также обеспечивают возможность трехкратного замера на протяжении одного бита. В таком случае, замер происходит на границах двух квантов, предшествующих точке замера и результат зависит от мажоритарного декодирования (это верно как минимум в случае 82527).

Тактовая синхронизация

Для того, чтобы регулировать встроенный в чип генератор тактовых частот шины, контроллер CAN может сократить или удлинить бит на целое число квантов. Максимальное количество таких временных поправок бита определяется параметром «ширина скачка синхронизации» (Synchronization Jump Width, SJW).

Жесткая синхронизация происходит при переходе стартового бита от рецессивного к доминантному. Отсчет времени прохождения бита начинается заново с этой границы.

Повторная синхронизация происходит когда край бита не попадает в сегмент синхронизации сообщения. Один из сегментов фазы укорачивается или удлиняется на некоторое количество квантов, зависящее от ошибки фазы сигнала; максимальное количество используемых квантов определяется параметром «ширина скачка синхронизации» (Synchronization Jump Width, SJW).

Вычисление регистра тактовой синхронизации

Большинство контроллеров CAN позволяют программисту осуществлять настройку тактовой синхронизации используя следующие параметры:

• Значение предварительного делителя тактовой частоты

• Количество квантов перед точкой замера

• Количество квантов после точки замера

• Количество квантов в «ширина скачка синхронизации» (Synchronization Jump Width, SJW)

Обычно для этих целей выделяется два регистра: btr0 и btr1. Однако они могут слегка различаться у разных контроллеров, поэтому внимательно читайте инструкцию.

В контроллерах 82c200 и SJA1000, производства NXP (ранее Philips), раскладка регистра выглядит приблизительно так:

	7	6	5	4	3	2	1	0
btr0	SJW1	SJW0	BRP5	BRP4	BRP3	BRP2	BRP1	BRP0
btr1	SAM	TSEG22	TSEG21	TSEG20	TSEG13	TSEG12	TSEG11	TSEG10

• BRP0..BRP5 устанавливают значение предварительного делителя тактовой частоты

• SJW0..SJW1 устанавливают длину SJW

• TSEG10..TSEG13 устанавливают количество квантов перед точкой замера (стартовый бит не включен)

• TSEG20..TSEG22 устанавливают количество квантов после точки замера

• SAM при установке значения 1 производится три замера, при установке значения 0 – один замер

Примечание: реальные значения этих параметров несколько отличаются от значений, вписанных в регистр.

Пример: если сигнал генератора, подаваемый на SJA1000, имеет частоту 16 МГц, и мы желаем получить скорость передачи 250 кбит/с, с точкой замера в районе 62% всего бита, и SJW равным 2 квантам, мы можем установить –
BRP = 4, что дает продолжительность кванта 2 × 4 / 16000000 с = 500 нс, и

TSEG1 = 5, что дает 5 квантов перед точкой замера, и

TSEG2 = 3, что дает 3 кванта после точки замера.

Каждый бит будет содержать 5 + 3 = 8 квантов, что даст нам желаемую скорость передачи 1 / (8 × 500 нс) = 250 кбит/с. Значения регистра должны быть следующими:

btr0=	(SJW – 1) * 64 + (BRP -1) = (2-1)*64 + (4-1) = 67 = 0×43
btr1=	SAM * 128 + (TSEG2 – 1)* 16 + (TSEG1 – 1) = 0×128 + (3-1)*16 + (4-1) = («4» потому, что стартовый бит не включен) 35 = 0×23

Точка замера в районе 5/8 = 62.5% бита.

Обработка ошибок CAN

Как CAN обрабатывает ошибки

Обработка ошибок встроена в протокол CAN и очень важна для производительности системы CAN. Обработк

www.micromax.ru