Сети промышленных контроллеров

CAN (controller area network) — сеть промышленных контроллеров или последовательная коммуникационная шина служит средством для объединения отдельных контроллеров в единую систему управления, работающую в реальном времени.

CAN (controller area network) — сеть промышленных контроллеров (иногда ее называют последовательной коммуникационной шиной) служит средством для объединения отдельных контроллеров в единую систему управления, работающую в реальном времени. В основе идеологии CAN лежит семиуровневая модель OSI/ISO. Спецификой CAN является то, что для реализации функций управления эта сеть должна обеспечивать надежный и высокоскоростной (до 1 Мбит/с) внутрисистемный обмен данными между контроллерами, с учетом неблагоприятных условий технологического окружения. CAN по своему определению объединяет ограниченное количество контроллеров, по своей природе она локальна и не выходит за рамки технологического объекта.

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

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

В настоящее время CAN успешно используется. Достижения в этой области, особенно на престижном «мерседесе» класса S (по-русски — «крутой» шестисотый), стимулировали продвижение идеи в другие отрасли. Сейчас CAN можно найти в системах морской навигации, управлении лифтами, сельскохозяйственных машинах, робототехнике, научной и медицинской аппаратуре, офисной технике и даже в сложных игрушках. Общее число сетей CAN в 2000 году превысило 100 млн., а сферы применения перекрывают диапазон от бытовой техники до космических аппаратов. Это вовсе неудивительно: замена кабельных монстров сетями (в простейшем случае телефонной «лапшой», витой экранированной или неэкранированной парой или даже оптоволокном) представляется очень привлекательной.

CAN и семиуровневая модель

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

Стандарты на CAN сформулированы в двух документах: ISO 11898 и ISO 11519. Соответствующее оборудование выпускается целым рядом крупнейших производителей; в их числе Bosch, NEC, Intel, Philips и целый ряд других компаний. Действующие стандарты пока распространяются только на два нижних уровня модели OSI/ISO — физический и канальный. Для физического уровня определена среда передачи, рекомендуемые типы соединений и разъемов, скорости передачи данных (10, 20, 50, 100, 250, 500, 800 кбит/с и 1 Мбит/с). На канальном уровне приняты стандарты Standard CAN и Extended CAN, которые определяют форматы сообщений (Message Frame). Логически они идентичны, но различаются числом разрядов в идентификаторе сообщения. В первом случае их только 11, во втором — 11 или 29. Обеспечивается совместимость сверху вниз. Об идентификаторах, изюминке CAN, мы поговорим чуть позже.

Протоколы верхних уровней модели, называемые HLP (High Level Protocol), стали активно развиваться только в последние годы, в связи с массовым распространением CAN, теперь уже вне традиционных автомобильных приложений. Как обычно бывает в таких случаях, эти протоколы предлагаются и развиваются компаниями-конкурентами. Кроме того, в целях стандартизации создаются картельные коммерческие и некоммерческие организации. Можно насчитать несколько десятков протоколов CAN HLP. Среди них наибольшее распространение получили CAL/CANopen, CAN Kingdom, DeviceNet и SDS (Smart Distributed System). Эти протоколы с исчерпывающей полнотой описаны в [1]. Общим для всех протоколов HLP является сжатие всех верхних уровней в один: для приложений CAN этого вполне достаточно.

Логика работы CAN

Принцип передачи данных в CAN часто, но не всегда, называют CSMA/BA (Collision Sense Multiple Access/Bitwise Arbitration). Из первой части названия следует, что он относится к категории CSMA (Carrier Sense, Multiple Access), где предполагается разделение доступа к носителю путем его прослушивания. Успех Ethernet сделал популярным другой вариант CSMA — с обнаружением коллизий CSMA/CD (Collision Detect). Вторую же часть названия CSMA/BA можно перевести как «побитный арбитраж»; в этом красивом способе разрешения коллизий и заключается специфика CAN.

В любой реализации CSMA носитель интерпретируется как эфир, в котором контроллеры, чаще их называют станциями, работают как приемники и передатчики. (Говорят, толчком к созданию Ethernet стало посещение Робертом Меткалфом Гавайских островов и знакомство с тамошней радиосетью AlohaNet.)

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

• Данные предаются квантованными сообщениями стандартного формата (телеграммами), поэтому исключаются все обычные сложности, присущие пакетной передаче с переменной длиной пакетов. Каждое сообщение включает только одно значение некоторого физического параметра, например, скорость вращения вала или температуру жидкости, назовем это типом сообщения, и идентификатор типа.
• Априорно предполагается, что количество станций и количество разных типов сообщений относительно невелики; в конечном счете, они ограничены технологической сложностью объекта управления. При таком допущении можно построить безадресную и абсолютно децентрализованную систему, где ни один передатчик не связан в своей работе с другими. Иными словами, имеет место, на первый взгляд, полная анархия, каждый котроллер пытается передать данные тогда, когда считает это необходимым, заботясь вовсе не о том, кто будет приемником. Его задача — передать. Поэтому все приемники вынуждены принимать все сообщения и отбирать по идентификатору только те, которые соответствуют их функциональной задаче. Скажем, система управления зажиганием принимает сообщения о скорости вращения двигателя и игнорирует данные о работе кондиционера.

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

Data Frame — фрейм передачи данных: «Привет всем, вот данные с идентификатором Х, получите».

Remote Transmission Request Frame или просто Remote Frame — фрейм запроса данных: «Привет всем, а может ли кто-нибудь выслать данные с идентификатором Х?»

Error Frame — служебный фрейм ошибки: «Стоп, начнем все с начала».

Overload Frame — служебный фрейм перегрузки контроллера: «Я очень занят, подождите чуть-чуть».

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

Рис. 4. Архитектуры BCAN и FCAN

Очень важно подчеркнуть, что, начав передачу, станция не прерывает слушание эфира, в частности она отслеживает и контролирует процесс передачи текущей предаваемой телеграммы, посланной ей самой.

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

Но передатчик и сам должен быть как-то уведомлен об успехе или неуспехе своей попытки, получив сообщение от контрагентов. Для этой цели в Data Frame имеется слот ACK (от английского acknowledgment — «подтверждение»), куда любой из контролеров, восприявших данный фрейм как адресованный ему, может занести запись о приеме. Передатчик отслеживает состояние этого слота и, если он не заполнен, будет повторять передачу до победного конца, пока подтверждение о приеме не будет получено.

Двуликий идентификатор

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

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

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

Двоичные значения «нуль» и «единица» наделены двумя качествами, явно заимствованными из генетики: «доминантный» и «рецессивный». Доминантный ген, как известно, подавляет рецессивный, например, ген черных волос подавляет ген светлых, в следствие чего количество натуральных блондинок уменьшается. В сети CAN доминантным считается «нуль», а «единица» — рецессивной. Результатом наложения на шине двух сигналов «нуля» с «единицей» будет «нуль»: если одновременно передаем два числа, то на гипотетическом осциллографе увидим меньшее. Если одновременно несколько станций начали передачу, и при этом произошла коллизия, происходит суперпозиция передаваемых идентификаторов. Идентификаторы последовательно, побитно (bitwise), начиная со старшего, налагаются друг на друга; в их противоборстве выигрывает тот, у кого меньше арифметическое значение идентификатора, а значит, выше приоритет. Доминантный «нуль» подавит единицы и в любом случае к концу передачи поля идентификатора оно станет равно более приоритетному значению.

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

CSMA/BA и другие способы распределения каналов

Для того чтобы сравнить CSMA/BA с другими способами разделенного доступа к каналу, введем две дихотомии.

Первая из них — отношение к ресурсу. В свое время аналогичным образом решалась задача разделения доступа к центральному процессору. Любой ресурс (процессора или носителя) можно каким-то образом квантовать по времени, выделяя каждому участнику обмена фиксированный фрагмент (token slot, token passing). С другой стороны его можно выделять по мере необходимости (по запросам) тому участнику обмена, кому в данный момент он нужен (CSMA/CD, Bitwise Arbitration, циклические перестановки).

Вторая дихотомия определяется отношением к сохранности передаваемых данных. Доступ к шине может быть неразрушающим, если шина выделяется по какому-то принципу монопольно на интервал времени одному из претендентов, и он доводит свою передачу до логического конца, сохраняя данные (token slot, token passing, Bitwise Arbitration, циклические перестановки). Напротив, CSMA/CD и Ethernet относятся к разрушающим методам резервирования каналов, при обнаружении в них коллизии прерываются все участвующие в ней передачи.

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

Работоспособности

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

Вторая составляющая механизма контроля — «имплантация бита» (bit stuffing), защищает от зависаний и других «глюков». По условиям в эфир подряд не может проходить более пяти битов одного значения. Если их набирается пять, то между ними вставляется дополнительный, служебный шестой, имеющий противоположное значение, в дальнейшем он просто фильтруется приемником. Но если его нет, то опять вырабатывается Error Frame.

Еще одна составляющая — мониторинг состояния контроллеров. Для контроллера обычным является активное по отношению к ошибкам (error-active) состояние, активное в том смысле, что оно предполагает способность генерировать фрейм Error Frame. Но при этом количество порожденных ошибок постоянно считается самим контроллером и, если оно достигает 96, то вырабатывается предупреждающий сигнал. Если же значение счетчика ошибок превысит 127, то контроллер переходит в пассивное (error-passive) состояние, в котором он продолжает выполнять регулирующую функцию, подсчитывая и дальше число ошибок, но при этом сигнал об ошибках Error Frame видоизменяется и теперь состоит из шести рецессивных бит и ни на что повлиять не в состоянии. Если в процессе работы число ошибок сократится, упадает ниже 128, то контроллер возвращается в активное состояние. Если же число ошибок еще больше возрастет и достигнет 256, то контроллер отключается от сети, переходя в состояние buss-OFF и ожидая обслуживания.

Рис. 5. Передача данных между сетями CAN

Об эффективности этих механизмов можно судить по данным, которые опубликованы в довольно популярном и многократно перепечатанном в Сети документе [2]. В нем оценивается вероятность возникновения ошибок, не обнаруженных описанными методами; их называют residual errors, т.е. остаточные или необъясненные ошибки. Утверждается, что в средней сети, состоящей из пяти — десяти станций, работающей по 8 часов 365 дней в году такая ошибка может возникнуть один раз за тысячу лет.

Базовый и полный

Существует два основных подхода к архитектуре интерфейса контроллеров с сетью. Первый — упрощенный Basic CAN (BCAN), второй — более сложный Full CAN (FCAN). Между ними есть еще промежуточное компромиссное решение Direct storage CAN — DCAN. Два первых различаются между собой механизмами буферизации сообщений. Если учесть, что каждая станция получает весь поток сообщений, циркулирующих в сети, то становится понятно: значительная часть процессорных ресурсов контроллера уходит на обработку сообщений. Возможны два выхода из этой ситуации, первый — снабдить контроллер производительным процессором, который бы справлялся с нагрузкой, а второй — усилить логику вспомогательной части контроллера, осуществляющей буферизацию и обработку сообщений. Чем эффективнее механизм буферизации, тем меньше загрузка процессора. Собственно, эти две полярные идеи развиваются в альтернативных решениях: BCAN — вся нагрузка на процессор, FCAN — минимизация нагрузки.

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

Интеграция сетей CAN

Как только сети CAN стали выходить за пределы таких относительно простых объектов автоматизации, как автомобили, где требуется автоматизировать ограниченное число функций, возникла необходимость интегрировать несколько сетей в одну систему управления [3]. Одна из главных причин — высокая, но, тем не менее, ограниченная пропускная способность шины. И здесь мы опять сталкиваемся со спецификой CAN, для которой пока не существует стандартных интеграционных решений, но известные весьма оригинальны.

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

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

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

Контроллеры со встроенными функциями межсетевого шлюза сегодня выпускают две компании. Из названия контроллера TwinCAN производства Infineon Technologies (английское twin означает «близнец») следует, что он способен подключаться к двум сетям одновременно. FCAN-контроллер ELIZA производства компании NEC включает 7 модулей подключения к сети и шлюзование между ними.

Литература

1. А. Щербаков, Сеть CAN: популярные прикладные протоколы. ChipNews, 1999, № 5
2. Controller Area Network, A Serial Bus System. CAN in Automation.
3. Jens Eltze, Thomas Lee, Integrated Controller Area Network Applications. NEC Electronics.

Введение в протокол 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 всегда выставлен в логический ноль (доминантный сигнал).

  Рис. 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 в Arduino – полное руководство

  Современные автомобили включают в себя несколько десятков разнообразных датчиков. И все эти датчики регулярно обмениваются информацией с другими датчиками/устройствами автомобиля. Причем автомобили с каждым годом становятся все «умнее» и поэтому количество датчиков в них все больше увеличивается. В автомобилях сегодняшнего дня находят широкое применение системы автономного вождения, системы безопасности с автоматически срабатывающими подушками безопасности, системы контроля давления в шинах, круиз-контроль и т.д. В большинстве случаев информация, поступающая от этих датчиков, является критически важной. Например, если сработает датчик столкновения, которому срочно нужно передать сигнал на раскрытие подушек безопасности, а ему это помешают сделать какие-либо сигналы/процессы в электронной системе автомобиля. В этом случае жизнь людей в автомобиле может оказаться под угрозой. Поэтому в автомобилях не используют такие широко распространенные в обычной электронике протоколы передачи данных как UART, SPI или I2C. Вместо них конструкторы автомобилей отдают предпочтение значительно более надежным протоколам передачи данных, таким как LIN, CAN, FlexRay и т.д.

  

  Наибольшее распространение среди этих «надежных» протоколов получил стандарт (протокол) CAN. Этот стандарт широко применяется не только в электронных системах современных автомобилей, но и во многих других промышленных устройства, в которых критически важна надежная передача данных. Достаточно подробную информацию о стандарте CAN можно прочитать в соответствующей статье Википедии. Мы же в данной статье рассмотрим обмен данными между двумя платами Arduino с помощью протокола CAN.

  Краткие сведения о протоколе CAN

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

  

  CAN-сеть состоит из двух проводников (CAN High и CAN Low) и обеспечивает двунаправленную передачу данных. На практике под CAN-сетью обычно подразумевается сеть топологии «шина» с физическим уровнем в виде дифференциальной пары. Передача ведется кадрами, которые могут принимать все узлы сети. Для доступа к такой шине выпускаются специализированные микросхемы (модули) – драйверы CAN-шины.

  Обычно скорость передачи по CAN-шине варьируется от 50 Кбит/с до 1 Мбит/с, а дальность связи лежит в диапазоне от 40 метров (на скорости 1 Мбит/с) до 1000 метров (на скорости 50 Кбит/с).

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

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

  Идентификатор (Identifier) – также известен под именами CAN ID и PGN (Parameter Group Number). Он используется для идентификации CAN устройств в CAN-сети. Длина идентификатора составляет 11 или 29 бит в зависимости от того какой тип протокола CAN используется:

  • Standard (стандартный) CAN: 0-2047 (11-bit);
  • Extended (расширенный) CAN: 0-2 29 -1 (29-bit).

  Data – это данные, которые необходимо передать от одного устройства другому. Длина данных может составлять от 0 до 8 байт.

  Data Length Code (DLC) (длина поля данных): может принимать значения от 0 до 8 в зависимости от количества байт для передачи.

  Проводники, используемые в CAN

  CAN протокол работает по двум проводникам, именуемыми CAN_H и CAN_L, для передачи и приема информации. Оба проводника работают как дифференциальная линия, что означает что CAN сигнал (0 или 1) представляет собой разность потенциалов между CAN_L и CAN_H. Если эта разность положительна и больше определенного минимального уровня напряжения, то это 1, а если эта разность отрицательна – то это 0.

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

  Сравнение CAN с SPI и I2C

  На нашем сайте мы ранее уже рассматривали использование в платах Arduino протоколов SPI и I2C, поэтому давайте сравним данные протоколы с протоколом CAN.

  быстрый: 400 Кбит/с;

  По скорости стандарт CAN не в лидерах, но его главным «козырем» является высокая надежность связи.

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

  1. В связи с чрезвычайно высокой надежностью и устойчивостью CAN протокола он широко применяется в автомобилях, промышленных механизмах, сельском хозяйстве, медицинском оборудовании и т.д.
  2. В связи с небольшим количеством используемых проводников CAN протокол исключительно удобен для применения в автомобилях.
  3. Устройства на основе CAN протокола отличаются низкой стоимостью.
  4. В CAN-сеть (шину) легко добавлять и удалять новые устройства.

  Использование протокола CAN в Arduino

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

  CAN модуль (контроллер шины CAN) MCP2515

  Модуль MCP2515 включает в себя CAN контроллер MCP2515, который представляет собой высокоскоростной CAN приемопередатчик. Соединение модуля MCP2515 с микроконтроллером осуществляется с помощью интерфейса SPI, поэтому его легко подключить ко всем микроконтроллерам с данным интерфейсом.

  

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

  Основные технические характеристики модуля MCP2515:

  • включает в себя высокоскоростной CAN приемопередатчик TJA1050;
  • размеры модуля: 40×28mm;
  • управление по интерфейсу SPI с возможностью подключения к CAN-шине нескольких устройств;
  • кварцевый генератор на 8 МГц;
  • сопротивление на концах 120 Ом;
  • включает независимый ключ, светодиодный индикатор, индикатор мощности;
  • поддерживает скорости передачи данных до 1 Мбит/с;
  • низкий потребляемый ток в режиме ожидания;
  • возможность подключения до 112 устройств (узлов).

  Назначение контактов (распиновка) CAN модуля MCP2515 представлено в следующей таблице.

  Наименование контакта	Назначение контакта
  VCC	контакт питания 5 В
  GND	общий провод (земля)
  CS	SPI SLAVE select pin (Active low) (выбор ведомого)
  SO	SPI master input slave output lead
  SI	SPI master output slave input lead
  SCLK	контакт синхронизации SPI
  INT	контакт прерывания MCP2515

  

  В данном проекте мы будем передавать данные, считываемые с датчика температуры и влажности DHT11 платой Arduino Nano, плате Arduino Uno с помощью CAN модуля MCP2515.

  Необходимые компоненты

  1. Плата Arduino Uno (купить на AliExpress).
  2. Плата Arduino Nano (купить на AliExpress).
  3. Датчик температуры и влажности DHT11 (купить на AliExpress).
  4. ЖК дисплей 16х2 (купить на AliExpress).
  5. MCP2515 CAN Module (контроллер шины CAN MCP2515) – 2 шт. (купить на AliExpress).
  6. Потенциометр 10 кОм (купить на AliExpress).
  7. Макетная плата.
  8. Соединительные провода.

  Схема проекта

  Схема проекта для связи между двумя платами Arduino с помощью протокола CAN и модулей MCP2515 представлена на следующем рисунке.

  

  Соединения на передающей стороне:

  Компонент — контакт	Arduino Nano
  MPC2515 — VCC	+5V
  MPC2515 — GND	GND
  MPC2515 — CS	D10 (SPI_SS)
  MPC2515 — SO	D12 (SPI_MISO)
  MPC2515 — S I	D11 (SPI_MOSI)
  MPC2515­ — SCK	D13 (SPI_SCK)
  MPC2515 — INT	D2
  DHT11 — VCC	+5V
  DHT11 — GND	GND
  DHT11­ — OUT	A0

  Соединения на приемной стороне:

  Компонент — контакт	Arduino Uno
  MPC2515 — VCC	+5V
  MPC2515 — GND	GND
  MPC2515 — CS	10 (SPI_SS)
  MPC2515 — SO	12 (SPI_MISO)
  MPC2515 — SI	11 (SPI_MOSI)
  MPC2515 — SCK	13 (SPI_SCK)
  MPC2515 — INT	2
  LCD (ЖК дисплей) — VSS	GND
  LCD — VDD	+5V
  LCD — V0	к среднему контакту потенциометра 10 кОм
  LCD — RS	3
  LCD — RW	GND
  LCD — E	4
  LCD — D4	5
  LCD — D5	6
  LCD — D6	7
  LCD — D7	8
  LCD — A	+5V
  LCD — K	GND

  Соединения между двумя CAN модулями MCP2515:

  H – CAN High
  L – CAN Low

  MCP2515 (Arduino Nano)	MCP2515 (Arduino UNO)
  H	H
  L	L

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

  

  Объяснение программы для Arduino

  Первым делом нам необходимо установить библиотеку для работы с протоколом CAN в Arduino IDE. Сначала скачайте ZIP файл библиотеки по следующей ссылке — Arduino CAN MCP2515 Library. Затем установите ее в Arduino IDE с помощью пункта меню Sketch -> Include Library -> Add .ZIP Library.

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

  Инициализация CAN модуля MCP2515

  Для установления соединения платы Arduino с модулем MCP2515 выполните следующую последовательность шагов. Но перед этим убедитесь в том, что указанная выше библиотека CAN MCP2515 установлена в вашу Arduino IDE.

  Шаг 1. Установите номер контакта, к которому подключена линия CS интерфейса SPI (10 по умолчанию).

  Источник https://www.osp.ru/os/2001/05-06/180162

  Источник http://can.marathon.ru/page/can-protocols/canbus/canintro

  Источник https://microkontroller.ru/arduino-projects/ispolzovanie-standarta-can-v-arduino-polnoe-rukovodstvo/