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

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

Протокол CAN, разработанный фирмой Bosch, изначально проектировался для нужд автомобильной промышленности оказался настолько удачным, что к настоящему моменту он применяется повсеместно.

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

конфигурационная гибкость;

получение сообщений всеми узлами с синхронизацией по времени;

неразрушающий арбитраж доступа к шине;

режим мультимастер;

обнаружение ошибок и передача сигналов об ошибках;

автоматическая передача сбойных сообщений при получении возможности повторного доступа к шине;

различие между случайными ошибками и постоянными отказами узлов с возможностью выключения дефектных узлов;

работает по витой паре на расстоянии до 1 км.

Типичными примерами применения CAN-сети являются системы контроля и управления текстильным оборудованием, производимого компаниями Cezoma, Lindauer Dornier, Rieter,
Schlafhorst, Sulzer.

Среди других важных областей применения сети нужно отметить промышленную автоматизацию и системы управление роботами. ABB, Bosch, Engel и другие компании уже применяют CAN в своем оборудовании. Edeka использует CAN в своем центре логистики Не обходятся без применения CAN-технологий системы автоматизации и жизнеобеспечения зданий, где они используются в управлении кондиционированием (Colt
International), поддержания температуры (Buderus), интегрированного контроля состояния помещений и освещения.

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

Устройства в CAN-системе соединяются по шине, состоящей из трех проводов (2 сигнальных и одни общий).

Сообщения данных, передаваемые из любого узла по
CAN-шине, могут содержать от 1 до 8 байт. Каждое сообщение помечено идентификатором, который в сети является уникальным (например, «Нагрев до 240», «Отказ нагрева», «Бункер загружен» и т. д.). При передаче другие узлы сети получают сообщение, и каждый из них проверяет идентификатор. Если сообщение имеет отношение к данному узлу, то оно обрабатывается, в противном случае – игнорируется. CAN-контроллер каждого из устройств может обрабатывать одновременно несколько идентификаторов (например, контроллеры Siemens и Intel могут обрабатывать до 15 идентификаторов). Таким образом, в каждом из устройств можно легко организовать несколько виртуальных каналов обмена информацией с различными устройствами, включая каналы одновременного получения сообщении.

Идентификатор определяет тип и приоритет сообщения. Более низкому числовому значению идентификатора соответствует более высокое значение приоритета. Сообщение, имеющее более высокий приоритет, передается раньше сообщения, имеющего более низкий приоритет. После сообщения с высоким приоритетом передается сообщение с более низким приоритетом, если во время передачи не помнится сообщение с более высоким приоритетом; затем передается сообщение с еще более низким приоритетом и т. д.

CAN содержит 5-ступепчатый механизм обнаружения ошибок:

циклический контроль по избыточности (CRC);

контроль передаваемого поля битов;

контроль сигнала «Подтверждение приема»;

текущий контроль логического уровня битов;

контроль заполнения битов.

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

Физический уровень CAN-интерфейса определяется стандартом ISO 11898 и характеризуется следующими возможностями: дифференциальное включение приемопередатчиков обеспечивает подавление синфазной помехи, при этом уровень сигналов составляет 1/3 от значения напряжения питания, причем, само напряжение питания не определяется жестко.

Например, типичные значения при напряжении питания +5 В приведены на рис. 5.18, причем доминирующим уровнем является нижний уровень, а рецессивным, соответственно, верхний;

максимальное расстояние между узлами – до 1 км;

скорость обмена до 1 Мбит/с при длине линии 60 м;

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

функции CAN, либо между микросхемой и остальной системой (рис. 5.19).

В CAN-протоколе определены следующие типы фреймов :

фрейм данных перемещает данные с передатчика на приемник (приемники);

удаленный фрейм запрашивает передачу фрейма данных, связанного с определенным идентификатором;

фрейм ошибки выражает, какой узел обнаружил ошибку шины/сети;

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

Рис. 5.18. Сигнальные уровни на CAN-шине

Рис. 5.19. Два типа гальванической развязки

Рассмотрим подробнее фрейм данных (рис. 5.20).

Рис. 5.20. Управляющее поле фрейма данных (окончание)

Он состоит из стартового поля SOF, поля арбитража Arbitration Field, управляющего поля Control Field, поля данных Data Field, поля контрольной суммы CRC, поля подтверждения ACK Field, поля конца фрейма EOF.

Поле SOF (Start of Frame) находится в начале фрейма данных и удаленного фрейма и содержит один доминирующий бит.

Поле арбитража Arbitration Field содержит 11-битовый идентификатор и RTR-бит, показывающий, является ли данный фрейм фреймом данных или удаленным фреймом. Идентификатор предназначен для адресации сообщений и используется механизмом арбитража.

Управляющее поле Control Field (см. рис. 5.20) содержит
6 битов, из которых 4 бита (DLC0-DLC4) составляют поле Data Length Code, показывающее количество байтов данных, которое будет передаваться в поле данных; два других бита зарезервированы для следующих редакций протокола.

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

Поле CRC обеспечивает механизм избыточного контроля по четности передаваемых данных.

Поле подтверждения ACK Field (см. рис. 5.21) содержит участки ACK Slot и ACK Delimiter и выполняет следующую функцию: передающий узел посылает по одному рецессивному биту на каждом из участков, а приемник, если он принял сообщение без сбоев, устанавливает на линии доминирующий бит в поле ACK Slot. При наложении рецессивного и доминирующего уровней на линии устанавливается доминирующий, и это событие сигнализирует передающему узлу о том, что передача прошла нормально и повтор не требуется.

Поле конца фрейма EOF содержится в фрейме данных и удаленном фрейме и состоит из семи рецессивных битов.

Рис. 5.21. Поле подтверждения фрейма данных

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

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

Поле арбитража, включенное во все фреймы данных, состоит из: 11-битового поля идентификатора; RTR-бита.

RTR-бит указывает, является ли фрейм фреймом данных или удаленным фреймом.

11-битовое поле идентификатора передается от старшего к младшему значащему биту. Доминирующий уровень – логический 0. Одновременная передача бита с доминирующим уровнем (логический 0) и бита с рецессивным уровнем (логическая 1) дает в результате уровень логического 0.

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

Важно следующее: идентификатор с самым низким значением выигрывает арбитраж.

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

При этом адрес приемника устанавливается в самом приемнике путем настройки входных фильтров соответствующих микросхем.

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

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

фиксированные – фильтры, которые требуют, чтобы биты соответствовали точно один к одному (one-for-one);

Mask-and-Match (маскируемые) – фильтры, которые применяют маску к полю идентификатора, прежде чем он сравнивается с приемным регистром кода.

В настоящее время СAN-протокол активно используется в индустриальных сетях. Такие известные фирмы, как Hoheywell и Allan_Bradley, разработали и поддерживают сетевые протоколы верхнего уровня SDS и DeviceNet, причем последний является открытым и на данный момент более 200 фирм выпускают и разрабатывают свои изделия в этом стандарте. Кроме того, достаточно известными в Европе являются стандарты сети верхнего уровня CanOpen, CAL (Германия) и CanKingdom (Швеция). Все эти сети используют CAN-протокол на физическом и транспортном уровнях. Ряд отечественных фирм также выпускает изделия с CAN-протоколом, в том числе в популярном формате MicroPC.

Интерфейс CAN был разработан в конце 80-х годов фирмой Bosch для связи электронных устройств, применяемых в автомобилях.

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

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

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

Согласно стандарту линия должна иметь волновое сопротивление в пределах 108-132 Ом. Для уменьшения отражений сигналов на каждом конце шины должны быть подключены согласующие резисторы RС сопротивлением 120 Ом. Для повышения надежности передачи и повышения помехоустойчивости иногда используют третий провод – общий, обозначаемый как GND. Питающее напряжение UCC (или UDD) по стандарту равно +5 В относительно GND.

Для абстрагирования от физической среды передачи спецификация CAN определяет два логических состояния (то есть логические 0 и 1) как рецессивное (recessive) и доминантное (dominant). При этом предполагается, что при передаче одним узлом сети рецессивного бита, а другим доминантного, принят будет доминантный бит.

В рецессивном состоянии (то есть логическая 1 на входе TxD трансивера) дифференциальное напряжение UDIFF =UCANH – UCANL меньше минимального порога (0,5 В на входе приемника или 0,05 В на выходе передатчика).

В доминантном состоянии (то есть логический 0 на входе TxD трансивера) дифференциальное напряжение UDIFF больше минимального порога (0,9 В на входе приемника или 1,5 В на выходе передатчика).

Сообщения в CAN. Интерфейс использует короткие сообщения: максимальный размер – 94 бита. Содержимое данных в CAN-сообщении как бы неявно определяет адрес источника этого сообщения и адреса приемников, кому эта информация необходима.

Например. один CAN-узел выдает на шину сообщение «Температура масла двигателя 80». Все другие узлы принимают это сообщение, но используют эту информацию только те узлы, кому она необходима.

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

1) кадр данных, используется для передачи данных;

2) кадр запроса данных, используется для дистанционного запроса данных от удаленного узла;

3) кадр ошибки, когда обнаруживаются ошибки на шине;

4) кадр перегрузки, передается для задержки передачи пакетов кадр данных и кадр запроса, например, при неготовности приемника.

Вид стандартного формата сообщения кадр данных приведен на рис. Он состоит из семи различных битовых полей:

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

Поле арбитража содержит 11-битный идентификатор ID и бит RTR – (запрос передачи данных). Для кадра данных этот бит должен иметь доминантный уровень.

Управляющее поле состоит из шести битов. Два самых старших бита в настоящее время не используются. Четырехбитный код длины данных указывает число байтов в поле данных.

Поле данных содержит от нуля до восьми байтов данных.

Поле контрольной суммы включает в себя контрольную сумму сообщения (15 бит) и бит-разделитель рецессивного уровня.

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

Поле конца кадра состоит из семи битов рецессивного уровня.

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

последовательная магистраль, обеспечивающая увязку в сеть "интеллектуальных" устройств ввода/вывода, датчиков и исполнительных устройств некоторого механизма или даже предприятия. Характеризуется протоколом, обеспечивающим возможность нахождения на магистрали нескольких ведущих устройств, обеспечивающим передачу данных в реальном масштабе времени и коррекцию ошибок, высокой помехоустойчивостью. Система CAN обеспечена большим количеством микросхем, обеспечивающих работу подключенных к магистрали устройств, разработку которых начинала фирма BOSH для использования в автомобилях, и в настоящее время широко используемых в промышленности и жилом секторе в составе автоматизированных систем контроля и учета электроэнергии (АИС КУЭ)

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

Расстояние, м	25	50	100	250	500	1000	2500	5000
Скорость, Кбит/с	1000	800	500	250	125	50	20	10

Максимальное число абонентов, подключенных к данному интерфейсу фактически определяется нагрузочной способностью примененных приемопередатчиков.
Протокол CAN использует оригинальную систему адресации сообщений. Каждое сообщение снабжается идентификатором, который определяет назначение передаваемых данных, но не адрес приемника. Любой приемник может реагировать как на один идентификатор, так и на несколько. На один идентификатор могут реагировать несколько приемников.
Протокол CAN обладает развитой системой обнаружения и сигнализации ошибок. Для этих целей используется поразрядный контроль, прямое заполнение битового потока, проверка пакета сообщения CRC-полиномом, контроль формы пакета сообщений, подтверждение правильного приема пакета данных. Хемминговый интервал d=6. Общая вероятность необнаруженной ошибки 4.7x10-11
Система арбитража протокола CAN исключает потерю информации и времени при "столкновениях" на шине.
Интерфейс с применением протокола CAN легко адаптируется к физической среде передачи информации. Это может быть дифференциальный сигнал, оптоволокно, просто открытый коллектор и т.п. Несложно делается гальваническая развязка.
, поддерживающие CAN, широко выпускается в индустриальном исполнении. И встречаются повсеместно, как на промышленных предприятиях, так и в структурах ЖКХ, жилом секторе, в частных домах, садоводческих товариществах (СНТ) и тд.

Примерный перечень счетчиков электроэнергии поддерживающих интерфейс CAN

Валюта магазина рубли у.е.

CAN шина. Часть 1.

1. Локальная сеть контроллеров (CAN)

Области применения.

Электронные распределители, Автомобили, Морские суда, Гидравлическое оборудование, Текстильная Промышленность, Перерабатывающая промышленность, Медицинское оборудование, Железная дорога, Строительная автоматизация, Авиационная радиоэлектроника, Бытовые приборы, Вооруженные силы, Обработка материалов, Сельское хозяйство, Телекоммуникация, Грузовики, Строительные Машины и Транспортные средства, Индустриальная автоматизация.

Общие сведения

Локальная сеть контроллеров CAN это стандарт серийной шины, разработанный в 80-х годах Robert Bosch GmbH, для соединения электронных блоков управления. CAN был специально разработан для устойчивой работы в насыщенной помехами окружающей среде с применением разносторонне сбалансированной линии, такой как RS-485. Соединение может быть более устойчивым к помехам при использовании витой пары. Первоначально создавалась для автомобильного назначения, но в настоящее время используется в разнообразных системах управления, в т.ч. индустриальных, работающих в насыщенной помехами окружающей среде.
Скорость обмена данными до 1Mbit/s возможна в сетях протяженностью не более 40м. Снижение скорости обмена позволяет увеличить протяженность сети, например - 250 Kbit/s при 250м.
CAN протокол связи стандартизирован согласно ISO 11898-1 (2003). Этот стандарт главным образом описывает слой обмена данными состоящий из подраздела логического контроля (LLC) и подраздела контроля доступа (MAC), и некоторых аспектов физического слоя ISO/OSI модели. Остальные слои протокола оставлены на усмотрение разработчика сети.

CAN сети и их разновидности

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

Общая характеристика

Интегрированная серийная коммуникационная шина для приложений работающих в режиме реального времени.
. Сеть работоспособна при скорости обмена данными до 1Mbit/s.
. Обладает превосходными возможностями обнаружения и проверки ошибок и неисправностей.
. Изначально CAN шина разработана для применения в автомобилях
. Используется в различных автоматических системах и системах управления.
. Международный стандарт: ISO 11898

Определение CAN

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

Свойства CAN

CAN система на серийной шине с мультифункциональными возможностями, все CAN узлы способны передавать данные и некоторые CAN узлы могут запрашивать шину одновременно. Передатчик передает сообщение всем CAN узлам. Каждый узел, на основании полученного идентификатора, определяет, следует ли ему обрабатывать сообщение или нет. Идентификатор так же определяет приоритет, который имеет сообщение при доступе к шине. Простота определяет стоимость оборудования и затраты на обучение персонала. CAN микросхемы могут быть относительно просто запрограммированы. Вводные курсы, функциональные библиотеки, наборы для начинающих, различные интерфейсы, I/O модули и инструменты в широком разнообразии представлены в открытой продаже по доступным ценам. С 1989 года CAN микросхемы могут быть свободно и просто соединены с микроконтроллерами. В настоящее время в наличии около 50 CAN микросхем для микроконтроллеров более чем 15 производителей.
CAN применяется в большинстве Европейских легковых автомобилях, а так же решение производителей грузовиков и внедорожников в дальнейшем применять CAN, определили развитие более чем на 10 лет. В других областях применения, таких как, бытовая сфера и индустриальный сектор наблюдается рост продаж CAN оборудования, и будет продолжаться в будущем. К весне 1997 года уже насчитывалось более чем 50 миллионов установленных CAN узлов. Одна из выдающихся особенностей CAN протокола высокая надежность обмена данными. CAN контроллер регистрирует ошибки и обрабатывает их статистически для проведения соответствующих измерений, CAN узел, являющийся источником неисправности, в результате будет отстранен от соединения.
Каждое CAN сообщение может содержать от 0 до 8 бит пользовательской информации. Конечно, возможна передача более продолжительных данных с применением фрагментации. Максимальная специфицированная скорость обмена 1 Mbit/s. Это возможно при протяженности сети не более 40м. Для более длинной коммуникации скорость обмена должна быть снижена. Для дистанции до 500 м скорость 125Kbit/s, и для передачи более чем на 1 км допускается скорость 50 Kbit/s.

CAN приложения

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

Лицензия CAN

CAN протокол разработан Robert Bosch GmbH и защищен патентами.

Основные стандарты CAN

Далее перечислены некоторые международные CAN стандарты
. CAN стандарты:
o ISO 11898-1 - CAN протокол
o ISO 11898-2 - CAN высокоскоростная физическая структура
o ISO 11898-3 - CAN низкоскоростная физическая структура совместимая с ошибками
o ISO 11898-4 - CAN запуск
o ISO 11898-5 - Высокоскоростное низковольтное устройство (в разработке).
o ISO 11519-2 - заменен на 11898-3.
. ISO 14230 - "Keyword Protocol 2000" - диагностический протокол использующий серийную линию, не CAN
. ISO 15765 - Диагностический протокол по CAN bus - Keyword 2000 на CAN bus.
. J1939 - Основной CAN протокол для грузовиков и автобусов определенный SAE
. ISO 11783 - J1939 и дополнение для сельхоз машин
. ISO 11992 - определяет интерфейс тягачей и прицепов
. NMEA 2000 - Протокол основанный на J1939 для судов, определен NMEA.

Преимущества CAN:

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

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

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

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

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

2. CAN шина

Введение

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

CAN протокол

CAN определен стандартом ISO 11898-1 и включает следующие основные сведения.
. На физическом уровне, сигнал передается, используя витую пару.
. Для контроля к доступу шины применяются правила арбитража.
. Блоки данных небольшие по размеру (в большинстве случаев 8 байт) и защищены чексуммой.
. Блоки данных не имеют адресации, вместо того каждый блок содержит числовое значение, которое определяет приоритет передачи по шине, так же может нести идентификатор содержания блока данных.
. сложная схема обработки ошибок, которая приводит к повторной передаче данных, которые должным образом не получены.
. Эффективные действия по изоляции неисправностей и отключение источника неисправности от шины.

Протоколы высшего порядка (HLP)

CAN протокол определяет безопасную передачу небольших пакетов данных из пункта А в пункт Б используя общую линию коммуникации. Протокол не содержит средств контроля потока, адресацию, не предоставляет передачу сообщений более чем 8 бит, не осуществляет установку соединения и т.д. Перечисленные свойства определяются HLP(Higher layer protocol) или Протокол Высшего Порядка. Условия HLP получены и состоят из семи порядков OSI модели.

Назначение HLP
. Стандартизация процедур запуска и установка скорости передачи
. Распределение адресации устройств и разновидности сообщений.
. Определение порядка сообщений
. обеспечивает механизм определения неисправностей системного уровня

CAN продукты

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

Патенты в области CAN

Патенты в отношении CAN приложений могут быть различных видов и направлений. Далее несколько видов:
. Синхронизация и реализация частоты передачи
. Передача больших блоков данных (CAN протокол использует фреймы длинной не более 8 бит)
Системы контроля распределения
CAN протокол продуктивная база для создания систем контроля распределения. Метод арбитража обеспечивает возможность каждого CAN устройства взаимодействовать с сообщениями относительно этого устройства.
Система контроля распределения может быть заявлена как система, в которой возможности процессора распределены среди устройств системы, или же наоборот, как система с центральным процессором и локальными I/O устройствами.
При разработке CAN сети могут быть применены различные совместимые аппаратные устройства, обладающие необходимыми свойствами и удовлетворяющие заданным или расчетным параметрам сети такие как, частота процессора, скорость передачи данных и т.д.

Действующие протоколы высшего порядка (HLP)

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

OSI модели (Open Systems Interconnect Model)
CanKingdom
CANopen/CAL
DeviceNet
J1939
OSEK
SDS
HLP обычно определяет
. Параметры запуска
. Распределение идентификатора сообщения среди различных устройств в системе
. Интерпретация содержимого блоков данных
. Статус взаимодействия в системе

Характеристика SDS, DeviceNet and CAN Kingdom.

И различия между CAN Kingdom and CANopen. В настоящее время насчитывается более 50 HLP. Применение HLP обязательно, в противном случае придется изобрести свой, собственный HLP.

CAnKingdom

CanKingdom поддерживается организацией CanKingdom International полная спецификация доступна на сайте организации.
CanKingdom обычно упоминается как CAN (Controller Area Network) протокол высшего порядка. В реальности наиболее упорядоченный протокол. Модули в системе соединены сетью, в которой один из модулей является главным (King). Например: для организации plug & play системы, главный модуль определяет какое устройство и при каких обстоятельствах может быть добавлено, разрешено добавление только специфицированных устройств. CanKingdom обеспечивает простую уникальную идентификацию устройств в системе, для этого используется стандарт идентификации EAN/UPC, индивидуальный идентификатор устройства определяется серийным номером устройства.
CanKingdom предоставляет разработчику все потенциальные возможности CAN.
Дизайнер не ограничен мультимастер протоколом CSMA/AMP и может создавать виртуальные системы управления шинами всевозможных разновидностей и топологии. Предоставляет возможность создания общих модулей без учета обстоятельств таких как, зависимость от HLP и свойств системы. Дизайнер может определить использование только специфических модулей, совмещая тем самым ценности открытой системы с преимуществами системы с ограниченным и безопасным доступом.

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

CAL and CANopen

CAL сокращенно от "CAN Application Layer" Порядок или слой CAN приложений, протокол поддерживается CiA. CAL разделен на несколько составных частей:
. CMS (CAN-based Message Specification) определяет протоколы передачи данных между CAN устройствами
. NMT (Network Management Service) определяет протоколы запуска и выключения, определения неисправностей, и т.д.
. DBT (Distributor Service) определяет протокол распределения идентификаторов различных устройств в системе
- CAL протокол отличный от OSI модели (Open Systems Interconnect (OSI) Model)
- CANopen является подразделом CAL, и скомпонован как набор профилей, которые не завершены окончательно.
- CAL/CANopen один из HLP действующих протоколов, поддерживаемых CiA.
- CAL и CANopen спецификации в полном объеме доступны и поддеживаются CiA

DeviceNet

Протокол развивается “Rockwell Automation nowadays”, определен организацией ODVA (Open DeviceNet Vendor Association). DeviceNet один из четырех протоколов, которые поддерживает CiA.

SAE J1939

J 1939 высокоскоростная сетевая коммуникация класса С разработанная для поддержки функций управления в режиме реальногго времени между контроллерами, которые физически расположены в различных местах автомобиля.
Jl708/Jl587 предыдущий, широко распространенный тип сети класса B с возможность обмена простой информацией, включая диагностические данные, между контроллерами. J1939 обладает всеми свойствами J1708/J1587.
J1939 использует CAN протокол с позволяет любому устройству передавать сообщение по сети в момент когда шина не загружена. Каждое сообщение включат в себя идентификатор, который определяет приоритет сообщения, информацию об отправителе данных, об информации, заключенной в сообщении. Конфликты избегаются благодаря механизму арбитража, который активизируется с передачей идентификатора (используется безопасная схема арбитража). Это позволяет сообщениям с наивысшим приоритетом передаваться с наименьшими задержками, по причине равного доступа к шине любым из устройств сети.
J1939 организован из нескольких частей основанных на (Open Systems Interconnect (OSI) Model). OSI модель определяет семь коммуникационных порядков (слоев), каждый представляет различные функции. В то время как есть документ J1939, ассигнованный каждому слою, не все они явно определены в пределах J1939. Другие слои выполняют вторичные функции, описанные в другом месте. Физический Слой описывает электрический интерфейс коммуникаций (витая экранированная пара проводов, который может также быть упомянут как шина). Слой Канала связи описывает протокол или управляет структурой сообщения, получая доступ к шине, и обнаруживая ошибки передачи. Слой приложения определяет специфические данные, содержащиеся в каждом сообщении, посылаемом по сети.
Полный комплект спецификации можно приобрести в SAE, ниже приведен перечень документов
J1939 дополняется следующими документами:
J1939 Практические рекомендации по Контролю серийной передачи и коммуникационная сеть транспортного средства
J1939/11 Физический порядок (слой) - 250k bits/s, экранированная витая пара
J1939/13 Диагностические разъемы
J1939/21 Данные слоя связи
J1939/31 Слой сети
J1939/71 Слой приложений
J1939/73 Диагностика
J1939/81 Управление сетью

OSEK/VDX

OSEK/VDX является совместным проектом в автомобильной индустрии. Создан как промышленный стандарт открытой оконечной архитектуры для распределенных контроллеров транспортных средств. Операционная система в режиме реального времени, интерфейсы программных средств и задачи управления сетью специфицированы совместно. OSEK" (Open systems and the corresponding interfaces for automotive electronics.) Открытые системы и информационные интерфейсы для автомобильной электроники. VDX “Whicule Distributed eXecutive" Распределенные исполнители транспортного средства.
Компании совместно участвующие в разработке: Opel, BMW, DaimlerChrysler, IIIT - University of Karlsruhe, PSA, Renault, Bosch, Siemens, Volkswagen.
Официальный сайт: www.osek-vdx.org

Smart Distributed System (SDS)

SDS система, на основе шины для интеллектуальных датчиков и исполнительных устройств, с упрощенным процессом установки, предоставляет широкие возможности управления вводом - выводом. Посредством одного четырехпроводного кабеля SDS система может быть оборудована до 126 приборами с индивидуальным адресом. Дополнительная информация и спецификация по SDS доступна на сайте разработчика Honeywell. SDS один из действующих четырех протоколов поддерживаемых CiA.

Сравнительная характеристика основных HLP протоколов
Общие сведения

DeviceNet, SDS и CAN Kingdom основаны на ISO 11898 CAN коммуникационном протоколе и функционируют согласно требований CAN спецификации. Каждый CAN модуль, следующий определенному протоколу может быть подключен к CAN шине следующей тому же протоколу. В любом случае при подключении модулей, которые действуют по различными протоколам, в большинстве случаев проблемы возникают по причине конфликта интерпретации сообщений на уровне приложений. CAN Kingdom отличается от SDS и DeviceNet основным принципом: CAN Kingdom организуется главным узлом коммуникации (“King”) при запуске, в отличии от SDS и DeviceNet. Такая организация позволяет упростить разработку комплекса систем реального времени и сокращает необходимое количество модулей координирующих спецификации, часто обозначаемые как профили.
SDS эффективен при подключении I/O устройств, различных выключателей и датчиков к PLC , фактически представляет собой соединение между основным модулем и удаленными I/O устройствами.
DeviceNet открытая система, в которой все модули имеют равные права по пользованию шиной, и порядок пользования шиной определяется небольшим набором инструкций. Разработчик модулей системы может передать полномочия по управлению коммуникацией другим модулям, например основному модулю в предопределенном режиме Главный/подчиненный, но DeviceNet не имеет возможности передать полномочия другим модулям. Характеристики SDS с использованием I/O устройств и DeviceNet в режиме Главный/подчиненный сходны.
Can Kingdom протокол ориентированный на системы продуцирования, соединения и контроля и не поддерживает профили для цифровых и аналоговых устройств. Основная особенность протокола заключается в том что модуль, подключенный к системе только ожидает инструкции от главного устройства. Все CAN приоритеты и идентификаторы принадлежат и предоставляются главным устройством. Во время запуска каждый модуль конфигурируется основным устройством, определяются приоритеты и идентификаторы объектов продуцирующих и потребляющих. Основное устройство является главным, но только в период конфигурирования системы. Главное устройство не может быть внедрено в период коммуникационной сессии между работающими приложениями различных модулей. Основное устройство может быть удалено после конфигурирования и проверки комплектности, при том каждый модуль запоминает полученные инструкции в памяти.

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

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

Канальный и физический уровни CAN

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

Структура узла сети CAN

Рассматриваемый нами узел сети CAN состоит из микроконтроллера, CAN контроллера и приемопередатчика (рисунок 1). Чаще всего мы используем микроконтроллеры с встроенным CAN контроллером для упрощения схемы, но иногда используется автономный контроллер CAN с интерфейсом SPI (MCP2510). Далее приемопередатчик подключается к витой паре, на концах которой размещены согласующие резисторы (терминатор) с сопротивлением 120 Ом.

Рисунок 1 – Узел сети CAN

Для формирования логической единицы в витой паре, или свободной шине, на оба провода подается напряжение, равное половине разности напряжения между 0 или Vcc. Логическому нулю соответствует подача на провода линии дифференциального напряжения (рисунок 2).

Рисунок 2 – Логические уровни на CAN-шине

Шина CAN позволяет передавать данные со скоростью 1 Мбит/c при длине кабеля не более 40 м. В обучающей литературе написано, что при снижении скорости передачи до 10кбит/с можно добиться длины сети в 1.5км.

Пакет сообщения CAN

Формат сообщения CAN показан на рисунке 3.

Рисунок 3 – Пакет сообщения CAN

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

Идентификатор сообщения используется для идентификации данных, отправленных в этом пакете. Каждое отправленное сообщение принимается всеми узлами сети и в данном случае идентификатор позволяет понять конкретному устройству, необходимо ли обрабатывать данное сообщение. Максимальная длина сообщения 8 байт, но можно уменьшить это значение для сохранения пропускной способности шины CAN. Для примера ниже по тексту есть несколько скриншотов CAN сообщений из автомобильной сети.

Арбитраж на шине CAN

Если без подробностей, то первым по шине CAN всегда передается сообщение с наименьшим идентификатором.

Настройка скорости передачи данных по шине CAN

Скорость передачи данных по CAN шине настраивается за счет формирования квантов времени, а не как во многих других протоколах последовательной передачи данных за счет делителя скорости. В большинстве случаев используются скорости 10Кбит/c, 20Кбит/c, 50Кбит/c, 100Кбит/c, 125Кбит/c, 500Кбит/c, 800Кбит/c, 1MBaud и настройки для этих скоростей уже посчитаны. На рисунке 4 изображено окно выбора скорости в программе PcanView.

Рисунок 4 – Выбор скорости передачи данных в программе PcanView

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

Рисунок 5 – Время передачи одного бита

Первый сегмент всегда фиксирован и равняется одному кванту. Далее идет два сегмента Tseg1 и Tseg2 и количество квантов в каждом сегменте определяется пользователем и может быть равно от 8 до 25. Точка выборки находится между Tseg1 и Tseg2, т.е. в конце первого и в начале второго сегмента. Так же пользователь может определить ширину скачка синхронизации (Synchronization Jump Width - SJW) для подстройки битовой скорости принимающего устройства, который может быть в диапазоне 1 – 4 квантов времени.

Теперь приведем формулу расчета скорости (Пример расчета скорости для CAN контроллера SJA1000):

BTR = Pclk/(BRP * (1 + Tseg1 + Tseg2))

BTR – скорость передачи данных,

Pclk – частота работы CAN контроллера,

BRP – значение предделителя частоты генератора скорости передачи

Tseg1 – первый сегмент

Tseg2 – Второй сегмент

Для проверки возьмем уже посчитанную скорость 125Кбит/c и попробуем получить настройки вручную. Pclk возьмем 16 МГц.

BRP = 16МГц /(125K * (1 + Tseg1 + Tseg2))

Затем подбираем интервал передачи бита находящийся в диапазоне от 8 до 25 квантов времени, так что бы получилось целое значение BRP. В нашем случае если взять (1 + Tseg1 + Tseg2) = 16, то BRP будет равен 30.

SP = ((1 + Tseg1 + Tseg2) * 70)/100

Подставляем значения и получаем 16 * 0.7 = 11.2, что соответствует соотношению Tseg1 = 10, Tseg2 = 5, т.е. 1 + 10 + 5 = 16. Далее смотрим если Tseg2 >= 5, то SJW = 4, если Tseg2 < 5, то SJW = (Tseg2 – 1). В нашем случае SJW = 4.

Итого для получения скорости 125Кбит/c необходимо в параметрах указать, BRP = 30, Tseg1 = 10, Tseg2 = 5, SJW = 4.

P.S. Конфигурирование baud rate значительно отличается между старыми модулями USB-CANmodul (GW-001 и GW-002) с контроллером SJA1000 и новыми модулями sysWORXX с контроллером AT91SAM7A3. В статье описывающей работу с бортовым CAN автомобиля на скорости 83кбит/c приведен расчет скорости для контроллера AT91SAM7A3.

Пример получения и передачи данных по CAN-интерфейсу

В примере будем использовать CAN-адаптер с программой PcanView от SYSTEC и подключимся к салонному CAN автомобиля, работающему со скоростью 125Кбит/с. Рассматриваемый нами автомобиль оснащен креслами с электроприводом и поэтому исследуем данные отвечающие за положение кресел и постараемся изменить положение спинки подменив пакет с помощью компьютера.

Для начала на схеме автомобиля находим наиболее удобно расположенный разъем с линиями CANH и CANL и подключаем к нему наш адаптер. Если разъем и провода найти не получилось, то можно подлезть к блоку управления кресла, найти там два скрученных между собой провода и аккуратно надрезав провода подключить адаптер. Если после подключения и настройки адаптера сообщения не приходят, то в первую очередь попробуйте поменять между собой CANH CANL и проверить включено ли зажигание.
Далее запускаем программу PcanView, в открывшемся окне настроек устанавливаем Baudrate = 125Кбит/c и нажимаем ОК (рисунок 4). В следующем окне устанавливаем Message filter = Standard, диапазон адресов от 000 до 7FF и нажимаем ОК (рисунок 6).

Рисунок 6 – Настройка CAN фильтра

Если все сделано правильно, то мы увидим сообщения от кресел (рисунок 7), а при нажатии кнопки наклона спинки на пульте управления мы увидим еще одно сообщение с адресом 1F4 идущее от пульта к креслу (рисунок 8).

Рисунок 7 – CAN сообщения от кресла с электроприводом

Рисунок 8 – CAN сообщения от кресла с электроприводом и сообщение от пульта управления к креслу

Теперь мы знаем какие должны быть адрес, длина и данные в CAN пакете для имитации нажатия кнопки изменения положения спинки. Во вкладке Transmit нажимаем NEW и в открывшемся окне создаем копию пакета 1F4, т.е. ID = 1F4, Length = 3, Data = 40 80 00. Period можно оставить 0 ms, тогда сообщения будут отправляться по факту нажатия кнопки пробел (рисунок 9).

Рисунок 9 – Создание CAN сообщения

На рисунке 10 отображено поле Transmit главного окна содержащее все отправляемые сообщения в CAN и информацию о них. При выделении сообщения и нажатии кнопки пробел произойдет отправка пакета в CAN сеть и кресло немного сдвинется в нужном направлении.

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

Итог

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