Наиболее часто используемый тип сообщения. Он состоит из следующих основных частей (рис. 4):

Рис. 4 Кадр данных стандарта CAN 2.0A

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

Поле арбитража (arbitration field) - используется в CAN для разрешения коллизий доступа к шине. Оно состоит из 11-битного идентификатора и поля RTR:

oидентификатор (Identifier field) - определяет важность содержимого кадра данных. Он неявно задает приоритет арбитража сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть;

oполе RTR (remote transmit request) - указывает, является ли данный кадр кадром удаленного запроса (рецессивный уровень) или кадром данных (доминантный уровень).

Флаг расширенного идентификатора (Identifier Extension Flag) - указывает, каким образом нужно интерпретировать последующие биты: как контрольные, или как задающие вторую часть 29-ти битового идентификатора.

Контрольное поле (control field) - содержит информацию о кадре и состоит из:

o2-х зарезервированных бит, находящихся всегда в доминантном состоянии;

oполя DLC (Data Length Code), которое содержит длину поля данных кадра. DLC указывается 4-х битовым кодом.

Поле данных (data field) - содержит от 0 до 8 байт полезных данных. Длина поля указывается кодом DLC.

Поле CRC (Cyclic Redundancy Check) - содержит 15-битную контрольную сумму сообщения и битовый разграничитель (всегда рецессив). Используется для обнаружения ошибок. Рассчитав CRC для блока принятых данных и сравнив его со значением, полученным от передающей стороны, принимающая сторона может определить некоторые типы ошибок. Проверка циклического избыточного кода выполняется на основе полинома, рассчитываемого как в передающем, так и в принимающем узлах.

Поле подтверждения ACK (acknowledge field) - состоит из двух бит: слота подтверждения и разделителя подтверждения.

ocлот подтверждения (Acknowledgement Slot) - первый бит поля подтверждения ACK. Устанавливается рецессивным со стороны передающего узла и доминантным со стороны всех получателей, которые осуществили успешную проверку CRC (циклического избыточного кода). Если передающий узел обнаруживает доминантное состояние этого бита, он может быть уверен, что хотя бы один узел принял сообщение без ошибок;

oразделитель подтверждения (acknowledge delimiter) - второй бит поля подтверждения CAN кадра. Является рецессивным. Доминантное значение разделителя считается нарушением формата и вызывает передачу кадра ошибки.

Конец кадра (End Of Frame) - состоит из семи рецессивных бит.

2.Кадр удаленного запроса (remote frame):

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

3.Кадр перегрузки (overload frame):

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

4.Кадр ошибки (error frame):

Это сообщение, которое явно нарушает формат сообщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Кадр состоит из флага ошибки (шесть бит одного знака) и разделителя ошибки (восемь рецессивных бит).

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

3.2.2Арбитраж доступа

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

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

Таким образом, в отличие, например, от Ethernet <#"justify">

Рис. 5 Побитовый арбитраж на шине CAN

3.2.3Методы обнаружения ошибок

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 - каждый узел, получив правильное сообщение по сети, посылает в сеть доминантный бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check - каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

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

4. Протоколы высокого уровня

Базовая спецификация CAN лишена многих возможностей, требуемых в реальных системах: передача данных длиннее 8 байт, автоматическое распределения идентификаторов между узлами, единообразное управление устройствами различных типов и производителей и пр. Все эти возможности являются предметом рассмотрения протоколов высокого уровня (HLP - Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

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

·SDS (Smart Distributed System) (Honeywell);

·DeviceNET (Allen Bradley);

·CAL\CANopen (CiA-ассоциация);

·Kingdom (Kvaser).

SDS - детище компании Honeywell Inc. Представляет собой недорогое и законченное решение для сетевого управления интеллектуальными датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации. По степени завершенности - от спецификаций физической среды до прикладного уровня. Архитектура протокола SDS включает в себя три уровня модели OSI/ISO - физический, канальный и прикладной. Шинная топология представляет собой линейную шину с короткими отводами.

DeviceNet - протокол высокого уровня для устройств на основе CAN. DeviceNet был разработан в 1994 году для автоматизации промышленных предприятий и детально описывает физический уровень CAN для обеспечения высокой совместимости и взаимозаменяемости готовых устройств. Служит для объединения в единую систему устройств промышленной автоматики, таких как фотодатчики, термодатчики, считыватели штрихкодов <#"center">5.Применение CAN

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

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

·CiA 408 - профиль CANopen устройства для гидравлических контроллеров и пропорциональных клапанов. Совместим с независимым от сети VDMA профилем;

·CiA 410 - профиль CANopen устройства для уклонометров. Поддерживает как 16-и, так и 32-х разрядные датчики;

·CiA 412 - профили CANopen устройств для медицинского оборудования. Определяют интерфейсы рентгеновских коллиматоров, генераторов рентгеновского излучения, медицинских стоек и столов;

·CiA 414 - профиль CANopen устройства для ткацких машин. Определяет интерфейс подающего механизма;

·CiA 415 - прикладной профиль CANopen для асфальтоукладчиков. Определяет интерфейсы различных устройств, используемых в дорожно-строительной технике;

·CiA 416 - прикладной профиль CANopen для дверей зданий. Определяет интерфейсы замков, сенсоров и других устройств, используемых в управляемых электроникой дверях;

·CiA 417 - прикладной профиль CANopen для лифтов. Определяет интерфейсы контроллеров кабины, дверей, контроллера вызова и других, а также узлов кабины и дверей, кнопочных панелей и др;

·CiA 418 - профиль CANopen устройства для батарейных модулей. Определяет интерфейс для работы с зарядными устройствами;

·CiA 419 - профиль CANopen устройства для зарядных устройств. Определяет интерфейс для работы с батарейными модулями;

·CiA 420 - семейство профилей CANopen устройства для экструдеров. Определяет интерфейсы для вытягивателя, гофрирователя и распиловщика;

·CiA 422 - прикладной профиль CANopen для муниципальных транспортных средств. Используется, в частности, для управления дополнительным оборудованием мусороуборочных машин и определяет интерфейсы таких подсистем, как прессовщик, весы и др.;

·CiA 425 - CANopen профиль для вспомогательных медицинских устройств. Определяет plug-and-play интерфейсы инжектора контрастного вещества и электрокардиографа.

Заключение

Протокол CAN оптимизирован для систем, в которых должно передаваться относительно небольшое количество информации (по сравнению с USB или Ethernet) к любому или всем узлам сети. Он обладает большим количеством преимуществ, среди которых:

·Множественный доступ с опросом состояния шины позволяет каждому узлу получить доступ к шине с учетом приоритетов.

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

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

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

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

Список использованной литературы

1.Древс Ю.Г., Зорин А.Л. Применение ПЭВМ в системах измерения и обработки данных. Часть 2. Технические средства сбора информации в измерительно-вычислительных комплексах: Учебное пособие. М.: МИФИ.

2.Карпенко 3.Е. Возможности CAN-протокола // Современные технологии автоматизации. - 1998 №4, с.16-20.

3.Любашин А.Н. Промышленные сети // Мир компьютерной автоматизации. - 1999. №1

.Третьяков С.А. CAN на пороге нового столетия // Мир компьютерной автоматизации. - 1999. №2

.Щербаков А. Протоколы прикладного уровня CAN-сетей // Современные Технологии Автоматизации. - 1999. №3

6. Robert Bosch GmbH «CAN Specification Version 2.0», 1991.

7.Зитцманн Рейнер, Мак Моника, Цельтвангер Хольгер, Шуманн Тило. CAN словарь. Второе издание. Пер. с англ. Грибов Игорь, 2005

8.IXXAT Automation GmbH. CAN vs. RS-485: Пер. с англ. ООО НПКФ «ДЭЙТАМИКРО», 2012

9.Pat Richards. AN228 - A CAN Physical Layer Discussion: Пер. с англ. PIClist, 2007

.ООО «Марафон». Введение в протокол CAN. - URL: http://can.marathon.ru/page/can-protocols/canbus/canintro

11.ООО «СМД Комп». Протокол CAN - оптимальное построение бортовой сети автомобиля. - URL: http://www.smd-component.ru/pdf/can-basic.pdf

12.Dmitry. Протокол CanOpen. URL: http://robot-develop.org/archives/4110

13.Протоколы прикладного уровня CAN-сетей: SDS (Smart Distributed System). URL: http://www.aldis.ru/techno/nets/can-protocols/sds/

14.Щербаков А. Сеть CAN: популярные прикладные протоколы. URL: http://catalog.gaw.ru/index.php?page=document&id=1428

Больше работ по теме: