Nd-avtodrom.ru

НД Автодром
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

Введение в протокол CAN

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

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

Рис. 1. Топология сети CAN.

CAN контроллеры соединяются с помощью дифференциальной шины, которая имеет две линии — CAN_H (can-high) и CAN_L (can-low), по которым передаются сигналы. Логический ноль регистрируется, когда на линии CAN_H сигнал выше, чем на линии CAN_L. Логическая единица — в случае когда сигналы CAN_H и CAN_L одинаковы (отличаются менее чем на 0.5 В). Использование такой дифференциальной схемы передачи делает возможным работу CAN сети в очень сложных внешних условиях. Логический ноль — называется доминантным битом, а логическая единица — рецессивным. Эти названия отражают приоритет логической единицы и нуля на шине CAN. При одновременной передаче в шину лог. нуля и единицы, на шине будет зарегестрирован только логический ноль (доминантный сигнал), а логическая единица будет подавлена (рецессивный сигнал).

Типы сообщений сети CAN.

Данные в CAN передаются короткими сообщениями-кадрами стандартного формата. В CAN существуют четыре типа сообщений:

  • Data Frame
  • Remote Frame
  • Error Frame
  • Overload Frame

Data Frame — это наиболее часто используемый тип сообщения. Он состоит из следующих основных частей:

  • поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть. Поле арбитража состоит в свою очередь из:
    • для стандарта CAN-2.0A, 11-битного идентификатора + 1 бит RTR (retransmit)
    • для стандарта CAN-2.0B, 29-битного идентификатора + 1 бит RTR (retransmit)

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

  • поле данных (data field) содержит от 0 до 8 байт данных
  • поле CRC (CRC field) содержит 15-битную контрольную сумму сообщения, которая используется для обнаружения ошибок
  • слот подтверждения (Acknowledgement Slot) (1 бит), каждый CAN-контроллер, который правильно принял сообщение посылает бит подтверждения в сеть. Узел, который послал сообщение слушает этот бит, и в случае если подтверждение не пришло, повторяет передачу. В случае приема слота подтверждения передающий узел может быть уверен лишь в том, что хотя бы один из узлов в сети правльно принял его сообщение.

Рис. 2. Data frame стандарта CAN 2.0A.

Remote Frame — это Data Frame без поля данных и с выставленным битом RTR (1 — рецессивные бит). Основное предназначение Remote кадра — это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Error Frame — это сообщение которое явно нарушает формат солобщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame. Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом. Error Frame состоит из поля Error Flag, которое состоит из 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing, см. ниже), и поля Error Delimiter, состоящее из 8 рецессивных битов. Error Delimiter дает возможность другим узлам сети обнаружив Error Frame послать в сеть свой Error Flag.

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

Контроль доступа к среде передачи (побитовый арбитраж).

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

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

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

CAN протокол определяет пять способов обнаружения ошибок в сети:

  • Bit monitoring
  • Bit stuffing
  • Frame check
  • ACKnowledgement Check
  • CRC Check

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

Bit stuffing — когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

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

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

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

Механизм ограничения ошибок (Error confinement).

Каждый узел сети CAN, во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). Все остальные узлы обнаруживают Error Frame и принимают соответствующие действия (сбрасывают принятое сообщение). Кроме того, каждый узел ведет два счетчика ошибок: Transmit Error Counter (счетчик ошибок передачи) и Receive Error Counter (счетчик ошибок приема). Эти счетчики увеличиваются или уменьшаются в соответствие с несколькими правилами. Сами правила управления счетчиками ошибок достаточно сложны, но сводятся к простому принципу, ошибка передачи приводит к увеличению Transmit Error счетчика на 8, ошибка приема увеличивает счетчик Receive Error на 1, любая корректная передача/прием сообщения уменшают соответствующий счетчик на 1. Эти правила приводят к тому, что счетчик ошибок передачи передающего узла увеличивается быстрее, чем счетчик ошибок приема принимающих узлов. Это правило соответствует предположению о большой вероятности того, что источником ошибок является передающий узел.

Каждый узел CAN сети может находится в одном из трех состояний. Когда узел стартует он находится в состоянии Error Active. Когда, значение хотя бы одного из двух счетчиков ошибок превышает предел 127, узел переходит в состояние Error Passive. Когда значение хотя бы одного из двух счетчиков превышает предел 255, узел переходит в состояние Bus Off.

Узел находящийся в состоянии Error Active в случае обнаружения ошибки на шине передает в сеть Active Error Flags. Active Error Flags сотстоит из 6 доминантных бит, поэтому все узлы его регистрируют. Узел в состоянии Passive Error передает в сеть Passive Error Flags при обнаружении ошибки в сети. Passive Error Flags состоит из 6 рецессивных бит, поэтому остальные узлы сети его не замечают, и Passive Error Flags лишь приводит к увеличению Error счетчика узла. Узел в состоянии Bus Off ничего не передает в сеть (не только Error кадры, но вообще никакие другие).

Адресация и протоколы высокого уровня

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

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

Рис. 4. Логическая структура протокола CAN.

Существует множество таких высокоуровневых протоколов. Наиболее распространенные из них это:

  • DeviceNet
  • CAL/CANopen
  • SDS
  • CanKingdom

Физичекий уровень протокола CAN

Физический уровень (Physical Layer) протокола CAN определяет сопротивление кабеля, уровень электрических сигналов в сети и т.п. Существует несколько физических уровней протокола CAN (ISO 11898, ISO 11519, SAE J2411).

В подавляющем большинстве случаев используется физический уровень CAN определенный в стандарте ISO 11898. ISO 11898 в качестве среды передачи определяет двухпроводную дифференциальную линию с импедансом (терминаторы) 120 Ом (допускается колебание импеданса в пределах от 108 Ом до 132 Ом. Физический уровень CAN реализован в специальных чипах — CAN приемо-передатчиках (transceivers), которые преобразуют обычные TTL уровни сигналов используемых CAN-контроллерами в уровни сигналов на шине CAN. Наиболее распространенный CAN приемо-передатчик — Phillips 82C250, который полностью соответствует стандарту ISO 11898.

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

скорость передачимаксимальная длина сети
1000 Кбит/сек40 метров
500 Кбит/сек100 метров
250 Кбит/сек200 метров
125 Кбит/сек500 метров
10 Кбит/сек6 километров

Разъемы для сети CAN до сих пор НЕ СТАНДАРТИЗОВАНЫ. Каждый протокол высокого уровня обычно определяет свой тип разъемов для CAN-сети.

CAN-интерфейс

Сетевой интерфейс CAN (Controller Area Network) был разработан в 1987г. (версия 1.0) фирмами BOSCH и INTEL для создания бортовых мультипроцессорных систем реального времени. Последняя спецификация интерфейса 2.0, разработанная фирмой BOSCH в 1992г., является дополнением предыдущей версии. В международной организации по стандартизации зарегистрирован ISO 11898 (для высокоскоростных приложений) и ISO 11519-2 (для низкоскоростных приложений).

Принцип работы

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

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

Рис. 1. Соединение устройств по CAN-шине

Идентификаторы

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

Физическая шина

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

Высокая надёжность

Для обеспечения безотказной работы в тяжёлых условиях по стандарту ISO11898 CAN-контроллер обеспечивает работу в сети в следующих случаях:

    любой из 3-х проводов в шине оборван,

любой провод — закорочен на питание,

любой провод — закорочен на общий провод.

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

Сетевая гибкость и лёгкость расширения

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

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

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

Арбитраж CAN-шины

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

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

Приоритет CAN-сообщения определяется двоичным значением его идентификатора.

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

Рис. 2. Соединение устройств по CAN-шине

Обнаружение Ошибок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждое переданное сообщение подтверждается приемником, и если этого не произошло, тогда устанавливается флаг ошибки подтверждения приема.

Флаг ошибки

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

С учетом действия всех механизмов контроля, реальное значение возникновения необнаруженной ошибки в CAN-системе – 10 -11 .

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

Стандартный CAN-протокол (версия 2.0A) поддерживает формат сообщения с 11-разрядными идентификаторами (Стандартное сообщение).

Расширенный CAN-протокол (версия 2.0B) поддерживает 11-битовый и 29-битовый форматы идентификаторов (Расширенное сообщение).

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

Контроллеры версии 2.0B могут посылать и получать сообщения в обоих форматах.

Различия форматов

В версии 2.0B поле битов идентификатора состоит из двух частей.

Первая часть (основная часть идентификатора) имеет длину одиннадцать битов для совместимости с версией 2.0A, вторая часть — восемнадцать битов (расширение идентификатора), что дает общую длину идентификатора в двадцать девять бит.

Для различения форматов используются биты Identifier Extension (IDE) и Substitute Remote Request (SRR) в Поле Арбитража.

Digitrode

цифровая электроника вычислительная техника встраиваемые системы

  • Вычислительная техника
    • Микроконтроллеры микропроцессоры
    • ПЛИС
    • Мини-ПК
  • Силовая электроника
  • Датчики
  • Интерфейсы
  • Теория
    • Программирование
    • ТАУ и ЦОС
  • Перспективные технологии
    • 3D печать
    • Робототехника
    • Искусственный интеллект
    • Криптовалюты

Чтение RSS

Что такое шина CAN и как она работает

Что такое интерфейс CAN и зачем он нужен

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

Первоначально изобретенный Bosch, а затем кодифицированный в стандарт ISO11898-1, интерфейс CAN определяет канал передачи данных и физический уровень модели взаимодействия открытых систем (OSI), обеспечивая низкоуровневое сетевое решение для высокоскоростной связи в автомобилях и промышленном оборудовании. В частности, CAN был разработан для уменьшения кабельной проводки в автомобилях, чтобы отдельные электронные блоки управления (ЭБУ) внутри транспортного средства могли обмениваться данными только по одной паре проводов. На следующем рисунке показаны ЭБУ автомобиля, подключенного к шине CAN.

Бортовая диагностика (OBD) – это система диагностики и отчетности автомобиля, которая позволяет устранять неполадки с помощью диагностических кодов неисправности (DTC). Когда загорается индикатор «проверьте двигатель» (check engine), техник часто использует портативное устройство для считывания кодов двигателя с автомобиля. На самом низком уровне эти данные передаются по протоколу, который в большинстве случаев является CAN.

DeviceNet – это сетевой протокол высокого уровня, используемый в промышленных приложениях. Это значительно уменьшает проводку, необходимую между системой управления и устройствами ввода/вывода. Вместо того, чтобы подключать каждое устройство к отдельному входу/выходу на модулях ввода/вывода ПЛК, устройства могут быть связаны друг с другом через четырехпроводный разъем и подключены к сетевому сканеру на ПЛК. На самом низком уровне мы находим, что CAN работает в рамках протокола DeviceNet. На следующем рисунке показан ПЛК, сканирующий сеть промышленных устройств, обменивающихся данными через DeviceNet.

Кадры сообщений CAN

Так как же на самом деле выглядит сообщение CAN? В первоначальном стандарте ISO изложено то, что называется стандартом CAN. Стандарт CAN использует 11-битный идентификатор для разных сообщений, что в сумме составляет 211, т. е. 2048, разных идентификаторов сообщений. CAN был позже изменен; идентификатор был расширен до 29 бит, что дало 229 идентификаторов. Это называется расширенной шиной CAN. CAN использует мультимастерную шину, где все сообщения транслируются по всей сети. Идентификаторы обеспечивают приоритет сообщения для арбитража.

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

Стандартный кадр CAN

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

Первый бит – это начало кадра (SOF). Этот доминирующий бит представляет начало сообщения CAN. Далее идет 11-битный идентификатор, который устанавливает приоритет сообщения CAN. Чем меньше идентификатор, тем выше приоритет сообщения.

Бит запроса удаленной передачи (RTR) обычно является доминантным, но он становится рецессивным, когда один узел запрашивает данные у другого. Бит расширения идентификатора (IDE) является доминантным, когда отправляется стандартный кадр CAN, а не расширенный. Бит r0 зарезервирован и в настоящее время не используется. Кусок кода длины данных (DLC) показывает, сколько байтов данных содержится в этом сообщении.

Далее идут сами данные, представляющие собой столько байтов, сколько представлено в битах DLC. Циклическая проверка избыточности (CRC) – это 16-битная контрольная сумма для обнаружения ошибок в передаваемых данных. Если сообщение принято правильно, принимающий узел перезаписывает рецессивный бит подтверждения (ACK) доминантным битом. ACK также содержит бит-разделитель для синхронизации. Конец кадра (EOF) означает конец сообщения CAN и имеет ширину 7 бит для обнаружения ошибок вставки битов. Последняя часть сообщения CAN – это межкадровое пространство (IFS), используемое в качестве временной задержки. Эта временная задержка точно соответствует времени, необходимому контроллеру CAN для перемещения полученного сообщения в буфер для дальнейшей обработки.

Расширенный кадр CAN

Расширенный кадр сообщения CAN использует 29-битный идентификатор вместе с несколькими дополнительными битами.

Расширенное сообщение имеет заменяющий бит удаленного запроса (SRR) после 11-битного идентификатора, который действует как заполнитель для сохранения той же структуры, что и стандартный CAN. На этот раз расширение идентификатора (IDE) должно быть рецессивным, что указывает на то, что за ним следует расширенный идентификатор. Бит RTR находится после 18-битного идентификатора, за ним следует второй резервный бит r1. Остальная часть сообщения остается прежней.

Типы сообщений CAN

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

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

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

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

Арбитраж и сигналы на шине CAN

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

Интересным аспектом шины CAN является то, что она использует инвертированную форму логики с двумя состояниями: доминантным и рецессивным. На рисунке ниже показана упрощенная версия вывода и ввода CAN-трансивера. Поток битов ‘101’ поступает с / идет на CAN-контроллер и / или микроконтроллер. Обратите внимание, что когда контроллер отправляет поток битов, они дополняются и помещаются в линию CANH. Линия CANL всегда является дополнением CANH. Чтобы арбитраж работал, устройство CAN должно отслеживать как то, что оно отправляет, так и то, что в данный момент находится на шине, то есть то, что оно получает.

Читать еще:  Мотоциклы с автоматической коробкой передач: лучшие представители класса

На следующем рисунке показаны сигналы CANH и CANL одновременно, так что вы можете видеть шину CAN в действии. Под сигналами шины изображено дифференциальное напряжение, которое соответствует доминантному и рецессивному состояниям сигналов CAN. Первые три сегмента во времени, t1 – t3, нарисованы так, чтобы соответствовать трем битам, показанным на предыдущем рисунке. Мы рассмотрим это с точки зрения драйвера вывода. Ввод драйвера изначально видит «1» и дополняет его до нуля, который помещается в CANH. CANL видит дополнение CANH и переводится в высокое логическое состояние. Это показано как t1 на рисунке. Обратите внимание, что напряжения CANH и CANL смещены относительно друг друга. В течение времени t1 дифференциал CANH — CANL очень близок к нулю, так как CANH и CANL имеют почти одинаковое напряжение. Этот период, когда драйвер посылает логику «1», в результате чего CANH и CANL близки к одному и тому же напряжению, мы называем рецессивным состоянием CAN.

Следующий отправленный бит – «0». CANH получает свое дополнение, и CANL снова получает дополнение CANH. Обратите внимание, что на этот раз напряжения CANH и CANL не близки друг к другу. Следовательно, дифференциальное напряжение (VDIFF) больше. Это CAN-доминантное состояние. Мы говорим, что логика инвертирована, потому что «1» приводит к понижению логического уровня шины, а «0» — к повышению. Входной приемник работает аналогично.

Как упоминалось ранее, чем меньше 11-битный идентификатор, тем выше приоритет сообщения. Каждый бит, который передает узел, он контролирует. Таким образом, узел обнаруживает, что сообщение с более высоким приоритетом размещается на шине. В тот момент, когда узел отправляет рецессивный бит, но обнаруживает доминантный бит на шине, он «отступает». Это называется неразрушающим арбитражем, потому что «победившее» сообщение продолжает передаваться без каких-либо проблем. Обратите внимание, что рецессивная логика «1» проигрывает доминантной логике «0». Это имеет смысл, поскольку более низкое значение идентификатора представляет более высокий приоритет. Чтобы лучше понять, что это значит, взгляните на следующий рисунок, на котором показаны три узла на шине CAN, пытающиеся получить контроль. Важно помнить, что каждый раз, когда отображается рецессивный бит, контроллер отправляет «1», в то время как доминантные биты соответствуют отправке «0».

Узлы 1–3 все посылают поток битов. Этот поток битов представляет идентификаторы сообщений и их приоритет. Для начала все три узла отправляют «1», который представлен на шине CAN как рецессивный бит. Затем каждый узел отправляет «0» или доминанатный бит. Третий бит, помещенный в шину – это еще один бит «1» или рецессивный бит. На этом этапе ни один из узлов не обнаружил никакого конфликта с другим узлом на шине, поэтому они продолжают передавать.

Для четвертого бита узел 1 отправляет «0» или доминантный бит. Узел 2 передает рецессивный бит, но обнаруживает доминантный бит на шине. Он немедленно «отступает», зная, что в данный момент отправляется сообщение с более высоким приоритетом. Узел 3 продолжает передачу, поскольку он считывает тот же доминантный бит, который он передал. Когда пятый бит помещается в шину, узел 3 затем распознает, что он имеет более низкий приоритет, и прекращает передачу. И узел 2, и узел 3 ждут определенное количество времени, прежде чем пытаться снова. Это показано в правой части рисунка, где выиграл арбитраж узел 3. Как видите, логический бит «0», соответствующий младшему идентификатору сообщения, позволяет проводить арбитраж.

Заключение

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

CAN протоколы высокого уровня

Введение

CAN протокол получил всемирное признание как очень универсальная, эффективная, надежная и экономически приемлемая платформа для почти любого типа связи данных в передвижных системах, машинах, техническом оборудовании и индустриальной автоматизации. Основанная на базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных систем автоматизации. Под терминами «CAN стандарт» или «CAN протокол» понимаются функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в соответствии с 7-ми уровневой OSI моделью. Таким образом, «CAN стандарт» соответствует уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация даже очень простых распределенных систем на базе CAN показывает, что помимо предоставляемых сервисов уровня канала данных требуются более широкие функциональные возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти дополнительные функциональные возможности непосредственно используются прикладным процессом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня. Обычно их и называют термином «CAN протоколы».

OSI модель протоколов высокого уровня на базе CAN,протоколов TCP/IP

Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми уровневой модели OSI(рис. 1). Это связано с тем, что типичная CAN система имеет в своей основе единственный канал данных для обмена сообщениями между устройствами, все устройства ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень приложений(рис. 2). Причем последний реализует некоторые функции транспортного уровня.

Рис. 1

Рис. 2

Из-за широко использования CAN сетей с различными целями и требованиями существуют несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP.

Основные возможности протоколов высокого уровня на базе CAN

Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня:

  • система назначения идентификатора для сообщения
  • метод обмена данных процесса
  • прямая(peer-to-peer) связь
  • метод установления связей для обмена данных процесса
  • сетевое управление
  • модели и профайлы устройств

Идентификаторы сообщений

Метод назначения идентификатора сообщения является главным архитектурным элементом CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет сообщения и следовательно время обработки сообщения (latency time). Это также влияет на возможность применимости фильтрования сообщения,на использование возможных коммуникационных структур и эффективность использования идентификатора. Что касается назначения идентификаторов сообщений, существуют различные подходы для систем на базе CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур системы, DeviceNet и SDS делают это.

Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в одной из 3-х групп в зависимости от приоритета сообщения (рис. 3).

Рис. 3

Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений — до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.

DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации (рис. 4):

Рис. 4

Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit) сообщениями между Master и Slave устройствами из предопределенного множества связей:

  • явный канал сообщений
  • изменение Master статуса канала (Master Poll Change of State/Cyclic channel)
  • изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel )
  • Bit Strobe канал

Явный канал сообщений главным образом служит для конфигурации устройства. С изменением Master статуса канала Master может запрашивать данные ввода — вывода от устройства и посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может запросить данные у любого из 64 Slave устройств посредством одного сообщения.

Oбмен данных процесса

Передача данных процесса между устройствами распределенной системы — цель системы на основе CAN протокола. Поэтому передача прикладных данных (данные процесса, данные ввода — вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet обеспечивают весьма схожие механизмы связи для передачи данных обслуживания / конфигурации процесса. У CANopen передача данных процесса происходит посредством так называемых «Объектов Данных Процесса (PDOs)», у DeviceNet посредством » I/O-сообщений «.

В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS. Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также поддерживаются 3 различных протокола (рис. 4) по отношению к подтверждению приема данных («Transport Classes») . Например, классы 2 и 3 могут быть использованы для эффективного опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты (connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2 или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных.

Таблица 1. Exchange of Process Data in CANopen, DeviceNet and SDS (Multicasting)

Рис. 5. Device Net Transport Classes

Вызов (triggering) сообщений

Все рассматриваемые протоколы поддерживают различные способы вызова сообщений. DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный (Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера и начинается передача сообщения. Передача по состоянию начинается, когда статус определенного объекта изменяется. В этом случае сообщение также передается, когда истекает определенный интервал времени, в котором не осуществлялась передача сообщения. Программным способом сам объект решает, когда начать передачу сообщения. В этом случае сообщение также передается, когда истекает определенный интервал времени без передачи сообщения.

Установление соответствий (mapping) для программных объектов

Сетевые устройства обычно содержат более одного программного объекта и передача I/O сообщения более чем одному программному объекту внутри одного PDO является необходимым требованием. В DeviceNet объединение прикладных данных осуществляется посредством трансляционных (assembly) объектов, которые определяют формат передаваемых данных. Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего (consumed/ produced_connection_path) может быть настраиваемой опцией устройства.

Прямые (peer-to-peer) коммуникационные каналы

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

DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.), сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit) сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На рис. 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific arguments).

Рис. 6. DeviceNet Fragemented Explicit Message Data Field Format (Request/Response)

Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы, которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit соединение в предопределенном множестве соединений. Запрос к устройству группы 2 передается как Explicit запрос без предварительного установления соединения (Unconnected Explicit Request ) с зарезервированным идентификатором сообщения.

Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых (peer-to-peer) коммуникационных каналов представлены в таблице 2.

CAN + CANOpen + CANfestival + STM32. Часть первая


Вы когда-нибудь участвовали в форумных склоках на тему «Что лучше — написать свое или взять готовое?». Лично я обожаю подобные вещи, причем я больше предпочитаю наблюдать, нежели участвовать. Ведь это так весело, сначала обсуждаются технические детали, потом постепенно переходят на личности, потом кого-то банят… Вы скажете, что я второсортное быдло, которому нравятся такие же второсортные развлечения? Знаете, а зачем это отрицать, зачем заниматься самообманом? Лучше принять себя таким, какой я есть, и гордо нести это как знамя: «Да, я — быдло!». Поэтому вместо самоотрицания я попытаюсь «набросить», и если мне повезет, то там, в комментариях разгорится такой спор переходящий от технический деталей к личным оскорблениям.
Так что может послужить предпосылкой такого спора? Ну вот, например, такая тема. Есть у вас в микроконтроллере замечательная штука — интерфейс CAN, помощью которого можно сделать массу замечательных вещей: шину для связи между модулями в умном доме, между узлами в собственном роботе, между модулями в ПЛК, между электроникой в автомобиле и т.д. и т.п. Но что пустить «поверх» CAN: свой самодельный протокол или взять готовый. А если готовой протокол, то что лучше свой самописный стек или готовый? Займу пожалуй одну из крайних позиций — все готовое, и протокол и стек к нему, а именно CANOpen и CANFestival.

Совсем без теории, к сожалению, не получится. Поэтому вкратце вот о чем:

  1. Пару слов о самом CAN
  2. О самом CANOpen
  3. И немного о CANfestival
Коротко о CAN

Почему именно CAN и чем он лучше, например, UART+RS485? На мой взгляд основное преимущество CAN состоит в побитовом арбитраже, который позволят «говорить» одновременно двум узлам на шине. Разумеется одновременно они говорить не будут, но благодаря этому механизму узлы «договорятся», кто скажет первый, а кто второй. Это происходит на уровне контроллера CAN и разработчику совершенно не нужно за этим следить. Это открывает возможность отправлять данные в шину асинхронно, если узлы хотят что-то передать, то «пусть говорят», когда хотят.

Минимальная единица передачи данных — фрейм. Если из фрейма выкинуть служебные составляющие, то доступные для использования разработчиком это 11-битный идентификатор, поле длинны и от 0 до 8 байт данных. По CAN’у этим ограничусь, если мало, то вот, например, хороший источник.

А вот с протоколом CANOpen двумя словами не отделаться.

Объектный словарь (Object dictionary) и что с ним делать

Представьте себе целую сеть из устройств, объединенных шиной CAN. Для того, чтобы однозначно различать эти устройства друг от друга, CANOpen вводит такое понятие, как Node Id (идентификатор узла). Этот Node Id во избежании недоразумений должен быть уникальным для каждого устройства на шине. Если кто-то знаком с протоколом Modbus, то он вероятно знает, что такое адрес ведомого устройства (Slave Address). Именно с этим адресом и можно провести аналогию для Node Id.
Источником данных в сети CANOpen служат объектные словари (object dictionary) узлов. Этот термин, как впрочем и все остальные, крайне редко встречается в различного рода литературе в переведенном на русский язык виде. Гораздо чаще приходится иметь дело именно с Object dictionary, а еще чаще с его аббревиатурой OD. Так вот OD это, что-то вроде двухуровневого списка или, может быть правильней, таблицы. Первый уровень пронумерован индексами от 0 до 65535. Второй уровень списка (или таблицы) пронумерован субиндексами от 0 до 255. В пунктах этого списка (или ячейках таблицы) и находятся данные, которыми обмениваются узлы в сети CANOpen. Таким образом, чтобы индексировать данные нужно два параметра индекс и субиндекс. Часто можно встретит запись в таком формате XXXXsubYY, где XXXX индекс в шестнадцатеричном формате, а YY то шестнадцатеричный субиндекс, например 1028sub03. Если продолжить строить аналогию с модбасом, то в модбасе есть карта регистров, а CANOpen есть объектный словарь OD. Вот только OD в отличии от карты регистров имеет более сложную структуру и имеет гораздо больше типов данных. Что за данные в нем лежат? Да что угодно — текущие значения аналоговых или дискретных входов, управляющие значения для выходных сигналов, настройки, сведения об устройстве и производителе и т.д. и т.п.

Для записи и чтения данных в/из OD, CANOpen предоставляет следующие сообщения:

  • SDO (service data object) — чтение и запись данных в OD по запросу.
  • PDO (process data object) — сообщения для отправки данных асинхронно (хотя не обязательно). Как правильно через эти сообщения передаются текущие измерения и управляющие сигналы

Читать и писать в объектный словарь может ведущий в сети CANOpen или, как его часто называют, «мастер» (master). Как правило, когда мастер настраивает какой-либо узел, он при помощи SDO записывает в OD интересующие его параметры. Формат сообщения с запросом на чтение или запиись зависит от типа SDO — короткое однофреймовое (expedited) или длинное многофреймовое (segmented). Expedited-формат предназначен для обмена небольшим объемом данных — до 4-ех байт, для всего что больше нужен формат segmented.

Однофреймовый expedited-запрос формируется следующим образом (см. картинку ниже):

  • 11-битный идентификатор = 0x600 + Node Id
  • Длинна = 8 байт
  • 0-ой байт данных — спецификатор команды, подробнее о нем ниже
  • 1-2 байты данных — соответственно младший и старший байты интересующего индекса OD
  • 3 байт — субиндекс OD
  • 4-7 байты — данные, если это запись


В нулевом байте css равен 2, если это команда на запись, 4, если запрос на чтение. Значение n немного не очевидное — это количество байт в сообщении, в которых НЕТ ДАННЫХ.

Ответ на такой запрос выглядит следующим образом:

  • 11-битный идентификатор = 0x580 + Node Id
  • Длинна = 8 байт
  • 0-ой байт данных — спецификатор команды
  • 1-2 байты данных — соответственно младший и старший байты интересующего индекса OD
  • 3 байт — субиндекс OD
  • 4-7 байты — данные, если это ответ на читающий запрос

Если запрос успешно выполнен то css будет равен 4, в случае же ошибки — 8. Всё остальное имеет тот же смысл, что и в запросе.
Для ясности приведу пример. Предположим, что нужно записать 4-ёх байтное число 0x12345678 в объектный словарь некоторого узла с Node Id равным 1 по индексу 0x2000 субиндексу 2. Фрейм с запросом будет выглядеть следующим образом:

ID = 0x601, len = 8, data = 0x23 0x00 0x20 0x02 0x78 0x56 0x34 0x12

Ответ в случае успеха будет выглядеть так:

ID = 0x581, len = 8, data = 0x60 0x00 0x20 0x02 0x00 0x00 0x00 0x00

Обращаю внимание, что данные во фрейме располагаются в порядке от младшего байта к старшему. Поэтому поле данных индекс представлен как 0x00 0x20, а данные идут байт за байтом 0x78 0x56 0x34 0x12.

Еще пример — запись 2-ух байт в индекс 0x2002 субиндекс 0x03:
Запрос
ID = 0x601, len = 8, data = 0x2B 0x02 0x20 0x03 0x34 0x12 0x00 0x00
Ответ
ID = 0x581, len = 8, data = 0x60 0x02 0x20 0x03 0x00 0x00 0x00 0x00

И еще пример — 1 байт в индекс 0x2003 субиндекс 0x04:
Запрос
ID = 0x601, len = 8, data = 0x2F 0x03 0x20 0x04 0x12 0x00 0x00 0x00
Ответ
ID = 0x581, len = 8, data = 0x60 0x03 0x20 0x04 0x00 0x00 0x00 0x00

Многофреймовый вариант, описывать не стану, во-первых лень, а во-вторых смысла особого нет, т.к. если использовать готовый стек (CANFestival), то он заботливо скроет от разработчика низкоуровневые подробности.

txPDO0: + Node ID, Len = 8, Data = [8 байт данных]
txPDO1: + Node ID, Len = 8, Data = [8 байт данных]
txPDO2: + Node ID, Len = 8, Data = [8 байт данных]
txPDO3: + Node ID, Len = 8, Data = [8 байт данных]

rxPDO0: + Node ID, Len = 8, Data = [8 байт данных]
rxPDO1: + Node ID, Len = 8, Data = [8 байт данных]
rxPDO2: + Node ID, Len = 8, Data = [8 байт данных]
rxPDO3: + Node ID, Len = 8, Data = [8 байт данных]

Таким образом каждый узел, может в совершенно любой момент времени отправлять до 32 байт и столько же принимать. Делать он это может по собственному желанию, никто его спрашивать не будет. Очень удобно, например, для измерений — свежие данные будут отправлены, когда будет закончено измерение, а не когда их запросят.
Источником данных для PDO служит объектный словарь, точнее некоторые его ячейки. Эти ячейки настраиваются, после чего стек CANOpen должен отправлять их содержимое в PDO каждый раз, когда они изменятся или периодически, или по команде в зависимости от опций.
Аналогично на приемной стороне настраиваются ячейки OD, куда будут попадать входящие PDO.

Network Management (NMT)

Каждый узел в сети CANOpen может находится в одном из многочисленных состояний:

  • Initialization — состояние сразу подачи питания;
  • PreOperational — «предбоевое» состояние. В это режиме узел уже шлет Heartbeat’ы (о них ниже), но еще не шлет и не принимает PDO;
  • Operational — «боевой» режим, в котором узел шлет и принимает PDO;
  • Stopped — режим полной остановки, узел будет недоступен даже по SDO. Предполагается, что в этот режим будут загонять устройство перед выключением.

Управление этими режимами осуществляется с помощью специальных сообщений имя которым NMT. Их формат следующий:

ID = 0x00, Len = 2, data = [cmd (1 байт)] [nodeId (1 байт)]

cmd принимает значения 1 — для перевода в режим Operational, 2 — Stopped, 0x80 — PreOperational; nodeId — это Node Id узла, режим которого хотят изменить.

Heartbeat’ы и Node Guarding

Вот в Modbus’е в некотором смысле все просто, если на узел отправили запрос, а он не ответил, то можно считать что он (узел) «помер». Но CANOpen запросы SDO используются только, чтобы настроить устройство, а в «боевом» режиме ведомое устройство может только «слушать» входящие PDO, если это какой-то модуль вывода сигналов, при этом совершенно ничего не отправляя в ответ. Как же понять, что подобный узел вообще в данный момент присутствует на шине? Для этого в CANOpen есть два механизма Heartbeat и Node Guarding. Как правило применяется один из двух, технически конечно можно зарядить и тот и другой, но я такого ни разу не видел.
Механизм Heartbeat’ов достаточно простой: каждый узел в сети с определенным периодом отправляет CAN фреймы следующего содержания:

ID = 0x700 + Node, ID Len = 1, data = [Mode (1 байт)]

Mode принимает значения 0x7F, если узел в режиме PreOperational, 0x05 — Operational, 0x00 — BootUp, 0x04 — Stopped. Значение BootUp отправляется самый первый раз, когда узел появляется на шине. Если от узла перестали приходить Heartbeat’ы, то можно диагностировать потерю связи.

Механизм Node Guarding исповедует прямо противоположный подход. Мастер периодически опрашивает при помощи NMT ведомые устройства на предмет их текущего режима. Нет ответа — нет узла.

Emergency

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

ID = 0x80 + Node Id, Len = 4..8, data = [Error Code(2 байта)] [Error Register(2 байта)] [Manufacturer Specific Error Field(0..4 байт)]

Error Code — это код ошибки, это коды частично стандартизованы протоколом, Error Register — об этом не в этот раз, Manufacturer Specific Error — код ошибки, который разработчики могут определять по своему усмотрению.

CANFestival

Есть такой замечательный человек — Эдуард Тиссерант (Edouard Tisserant). Он вместе с единомышленниками в свое время реализовал стек, который реализует всё вышеописанное и даже больше. Имя этому стеку CANFestival. Кстати говоря это далеко не единственное достижение Эдуарда, с его именем тесно связан проект Beremiz, с которым познакомил наше сообщество коллега Антон Мидюковantohami .

Ну так вот, в официальном репозитарии CANFestival помимо портов под Linux можно найти порты и под микроконтроллеры AVR. Подробно о том что в этом репозитарии, как портировать и создавать объектные словари и обособленные проекты расскажу во второй части, ибо силы писать эту статью уже кончились.

CAN-шина

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

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

В середине 80-х годов прошлого столетия компании Intel и Robert Bosch GmbH разработали цифровое устройство для обмена данных, которое стало стандартом автомобильной

электроники.

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

  • 1 Особенности устройства CAN-шины
  • 2 Передача данных по Кан-шине
  • 3 Обзор возможностей протокола CAN
  • 4 Скорость передачи данных CAN-шины
  • 5 Протоколы высокого уровня
  • 6 Достоинства и недостатки протокола CAN
Читать еще:  Что лучше Kia Rio или Chevrolet Cruze

Особенности устройства CAN-шины

Передаются данные, со скоростью 1Мбит/сек, по радиоканалам или на оптоволоконном уровне. Биты данных одномоментно превращаются в кадры (подобие ограниченных порций). Есть сложная схема разделения кадров на доминантные и рецессивные и приоритетов формирования очереди передачи, с применением арбитража. Однако в эти области высоких технологий, простому автолюбителю заглядывать нет никакой нужды.

На физическом уровне CAN-сеть – это непрерывная «шина» дифференциальной пары, в роли проводника информации, прописанной стандартом ISO. Доступ к ней осуществляется посредством драйвера CAN-шины.

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

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

В последних выпусках есть функции подключения к смартфонам.

Есть заложенная функция предвидения и устранения некоторых неполадок электрооборудования автомобиля. Даже электробрелки зажигания, подключаясь через CAN, получают необходимые данные от ЭБУ автомобиля.

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

Передача данных по Кан-шине

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

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

Тот, получив наказ на какое-либо действие, спешит его выполнить.

В покое, напряжение в проводах витой пары одинаковое и составляет 2,5В. Это, так называемое, рецессивное положение. Во время начала сеанса, провода приводятся в возбуждение участником, посылающим сообщение. Напряжение на одном из проводов (CAN High) начинает возрастать, достигая 3,5В. На другом (CAN low) – убывать, до достижения отметки 1В.

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

Обзор возможностей протокола CAN

  1. Продукты — микросхема, инструменты разработки, модули, инструменты проектирования;
  2. Распределение посланий — каждый участник будет иметь возможность выбирать к просмотру сообщения, касающиеся только его. Для этого предусмотрены фильтры;
  3. Широковещательный характер – если участник не выбрал только свои сообщения, то он имеет возможность просмотра всего потока информации;
  4. Контентная адресация – нет явного адресата. Выбираются адреса контента по идентификатору в самом сообщении;
  5. Виды сообщений – кадр данных, удаленный, ошибки, перезагрузки;
  6. СтандартныйCANи его расширенная версия – отличаются длиной установленного идентификатора. Если в станд. варианте он равен 11битам, то в его «толстом» собрате – 29 бит;
  7. Конфликтное разрешение и определение приоритета – чтобы избежать одновременной передачи данных несколькими участниками, выработан арбитражный механизм. Все пакеты поделены на доминантный и рецессивный. Не вдаваясь в подробности, отметим только, что всегда приоритет на стороне доминантного сообщения.
  8. Физические уровни:

— сигнальная сбалансированная двухпроводная схема high–speed CAN представляет вторую часть стандарта ISO 11898;

— третья часть ISO 11898 составляет следующий уровень вышеназванной схемы;

— однопроводной уровень, описываемый стандартом SAE J2411. Шины этого уровня установлены, например, на автомобилях линейки Дженерал Моторс.

  1. Прерывание конца – CAN-шина должна содержать на конце резисторное сопротивление (120ОМ), для гашения отражения сигнала, создания уровня постоянного тока.
  2. Кабель – сопротивление должно укладываться в интервал 108 – 132ОМ.
  3. Разъем – нет стандартов для разъемов CAN. Каждый протокол описывает свои предпочтения. Однако есть фактический стандарт для автопромышленности.
  4. Ошибка – контролер найдет ее и отметит флажком, разрушая передачу. Эти флажки станут знаком для всех участников цепи на ее сброс.
  5. Сбои в передачи – при различных сбоях дается возможность дальнейшего функционирования. Сбои могут быть разного характера: прерывание, короткое замыкание в разных частях, разъединение с оконечным сопротивлением.

Скорость передачи данных CAN-шины

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

В угоду ускорения процесса, разработчики уменьшают протяженность проводов, одновременно увеличивая число цепей, с возможностью подключения большего количества приборов. Например, общая длина шины, составляющая 10 метров, способна пропускать через себя кадры, со скоростью 2 Мбит/c, с 64 подключенными приборами. Если автомобиль снабжен большим числом электрооборудования, то добавляется одна, две, и т. д. цепи.

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

CAN всего лишь решает проблему доставки информации из одного пункта в другой, малыми пакетами (всего 8 байт). Многие аспекты обмена данных, остаются вне его компетенции. Ввиду большого спроса на рынке, незамедлительно, появились разработки усовершенствованных протоколов – так называемые, протоколы высокого уровня. Они взялись оказывать более расширенный пакет услуг. Ими пользуются, когда нужно:

  • Задать стандарты запуска, в т.ч. скорости обмена;
  • Распределение, предварительно распознанных, адресов взаимодействующих элементов и видов сообщений;
  • Точная разметка послания;
  • Порядок разбора ошибок.

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

Протокол CAN вошел в состав стандартного протокола OBD-II.

К несомненным преимуществам CAN относятся:

  1. Передача информации в реальном времени;
  2. Простота и дешевизна использования;
  3. Помехоустойчивость;
  4. Обеспечение доступа, путем арбитража, без снижения пропускных характеристик сети;
  5. Контроль всех ошибок обмена данных;
  6. Большой интервал рабочих скоростей;
  7. Широкое его применение, большое разнообразие ассортимента от разных поставщиков.

К недостаткам относятся:

  1. Маленький объем одного пакета данных, который составляет не более 8 байт;
  2. Служебные данные занимают больше объема, чем передаваемые, что значительно влияет на скорость (разработчикам есть куда расширяться);
  3. Нет общего стандарта на протоколы повышенного уровня. В CAN можно прописать любой протокол, если его исполнение помещается в рамках пропускной способности CAN.

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

CAN протоколы высокого уровня

CAN протоколы высокого уровня

Введение

CAN протокол получил всемирное признание как очень универсальная, эффективная, надежная и экономически приемлемая платформа для почти любого типа связи данных в передвижных системах, машинах, техническом оборудовании и индустриальной автоматизации. Основанная на базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных систем автоматизации. Под терминами «CAN стандарт» или «CAN протокол» понимаются функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в соответствии с 7-ми уровневой OSI моделью. Таким образом, «CAN стандарт» соответствует уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация даже очень простых распределенных систем на базе CAN показывает, что помимо предоставляемых сервисов уровня канала данных требуются более широкие функциональные возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти дополнительные функциональные возможности непосредственно используются прикладным процессом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня. Обычно их и называют термином «CAN протоколы».

OSI модель протоколов высокого уровня на базе CAN,протоколов TCP/IP

Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми уровневой модели OSI(рис. 1). Это связано с тем, что типичная CAN система имеет в своей основе единственный канал данных для обмена сообщениями между устройствами, все устройства ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень приложений(рис. 2). Причем последний реализует некоторые функции транспортного уровня.

Рис. 1

Рис. 2

Из-за широко использования CAN сетей с различными целями и требованиями существуют несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP.

Основные возможности протоколов высокого уровня на базе CAN

Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня:

  • система назначения идентификатора для сообщения
  • метод обмена данных процесса
  • прямая(peer-to-peer) связь
  • метод установления связей для обмена данных процесса
  • сетевое управление
  • модели и профайлы устройств

Идентификаторы сообщений

Метод назначения идентификатора сообщения является главным архитектурным элементом CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет сообщения и следовательно время обработки сообщения (latency time). Это также влияет на возможность применимости фильтрования сообщения,на использование возможных коммуникационных структур и эффективность использования идентификатора. Что касается назначения идентификаторов сообщений, существуют различные подходы для систем на базе CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур системы, DeviceNet и SDS делают это.

Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в одной из 3-х групп в зависимости от приоритета сообщения (рис. 3).

Рис. 3

Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений — до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.

DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации (рис. 4):

Рис. 4

Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit) сообщениями между Master и Slave устройствами из предопределенного множества связей:

  • явный канал сообщений
  • изменение Master статуса канала (Master Poll Change of State/Cyclic channel)
  • изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel )
  • Bit Strobe канал

Явный канал сообщений главным образом служит для конфигурации устройства. С изменением Master статуса канала Master может запрашивать данные ввода — вывода от устройства и посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может запросить данные у любого из 64 Slave устройств посредством одного сообщения.

Oбмен данных процесса

Передача данных процесса между устройствами распределенной системы — цель системы на основе CAN протокола. Поэтому передача прикладных данных (данные процесса, данные ввода — вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet обеспечивают весьма схожие механизмы связи для передачи данных обслуживания / конфигурации процесса. У CANopen передача данных процесса происходит посредством так называемых «Объектов Данных Процесса (PDOs)», у DeviceNet посредством » I/O-сообщений «.

В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS. Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также поддерживаются 3 различных протокола (рис. 4) по отношению к подтверждению приема данных («Transport Classes») . Например, классы 2 и 3 могут быть использованы для эффективного опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты (connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2 или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных.

Таблица 1. Exchange of Process Data in CANopen, DeviceNet and SDS (Multicasting)

Рис. 5. Device Net Transport Classes

Вызов (triggering) сообщений

Все рассматриваемые протоколы поддерживают различные способы вызова сообщений. DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный (Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера и начинается передача сообщения. Передача по состоянию начинается, когда статус определенного объекта изменяется. В этом случае сообщение также передается, когда истекает определенный интервал времени, в котором не осуществлялась передача сообщения. Программным способом сам объект решает, когда начать передачу сообщения. В этом случае сообщение также передается, когда истекает определенный интервал времени без передачи сообщения.

Установление соответствий (mapping) для программных объектов

Сетевые устройства обычно содержат более одного программного объекта и передача I/O сообщения более чем одному программному объекту внутри одного PDO является необходимым требованием. В DeviceNet объединение прикладных данных осуществляется посредством трансляционных (assembly) объектов, которые определяют формат передаваемых данных. Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего (consumed/ produced_connection_path) может быть настраиваемой опцией устройства.

Прямые (peer-to-peer) коммуникационные каналы

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

DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.), сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit) сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На рис. 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific arguments).

Рис. 6. DeviceNet Fragemented Explicit Message Data Field Format (Request/Response)

Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы, которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit соединение в предопределенном множестве соединений. Запрос к устройству группы 2 передается как Explicit запрос без предварительного установления соединения (Unconnected Explicit Request ) с зарезервированным идентификатором сообщения.

Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых (peer-to-peer) коммуникационных каналов представлены в таблице 2.

Новичку о подключении к CAN шине

Для работы с CAN шиной автомобиля необходимо знать:

CAN шина – это сеть обмена данными определенная в стандарте ISO 11898. Другие каналы обмена данными в автомобиле не могут быть названы CAN шиной. AVC-LAN, BEAN, J1708, VAN и другие старые протоколы это НЕ CAN !

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

Скорости работы CAN шины

CAN на разных автомобилях и в разных сегментах сети может работать на разных скоростях.

Названия сегментов сети: Мотор, Шасси, Комфорт, Салон – условны! У Каждого автопроизводителя свои названия этих участков сети!

  • Группа VAG: Моторшасси – 500 кбитс, Комфорт – 100 кбитс и с 2018 года шина Комфорт может иметь скорость 500 кбитс., Диагностика: 500 кбитс.
  • BMW : МоторШасси – 500кбитс, Комфорт – 100 кбитс и с 2018 года шина Комфорт может иметь скорость 500 кбитс., Диагностика: 500 кбитс.
  • Mercedes-Benz : МоторШасси – 500 кбитс, Комфорт 83.333 кбитс, 250 кбитс, Диагностика: 500 кбитс.
  • Ford, Mazda : МоторШасси – 500 кбитс, Комфорт 125 кбитс. (Для Ford может быть больше вариантов)
  • KIAHyundai : МоторШасси – 500 кбитс, Комфорт 125 кбитс, 500 кбитс, Мультимедиа: 125 кбитс, 500 кбитс., Диагностика: 500 кбитс.
  • GM : МоторШасси – 500 кбитс, Комфорт: 33.333 кбитс, 95.2 кбитс, Диагностика: 500 кбитс.
  • Toyota, Nissan, Honda, Subaru, Suzuki : 500 кбитс (может использоваться гейтвей)
  • Mitsubishi : МоторШасси: 500 кбитс, СалонКомфорт – 83.333 кбитс, 250 кбитс, Диагностика: 500 кбитс.
  • Volvo : МоторШасси: 500 кбитс, СалонКомфорт – 500 кбитс, 125 кбитс, Диагностика: 500 кбитс.
  • Renault : 500 кбитс
  • Peugeot : МоторШасси – 500 кбитс, Комфорт 125 кбитс.
  • Lada : 500 кбитс
  • Коммерческая и специальная техника : Стандарт J1939 250 или 500 кбитс.

Сегментация CAN шины по функциональному назначению

  • Как правило разные, сегменты сети разделены специальным устройством, которое называется Гейтвей (Gateway, ZGW, ETACS, ICU) .
  • В роли гейтвея может выступать панель приборов (для простых автомобилей) или отдельный специальный модуль межсетевого интерфейса.
  • Гейтвей разделяет потоки данных в разных сегментах сети и обеспечивает связь сегментов сети работающих на разных скоростях.
  • ВАЖНО: На многих автомобилях (особенно VAG, MB, BMW) CAN шина в диагностическом разъеме OBD2 отделена от других участков сети при помощи гейтвея, поэтому подключившись к CAN шине OBD разъема невозможно увидеть поток данных. В этом случае можно увидеть только обмен между диагностическим инструментом и автомобилем во время процесса диагностики! Так же модулем гейтвеем оборудованы автомобили японских марок с 2016..2018 годов в зависимости от модели.
  • ОБЯЗАТЕЛЬНО изучайте схемы на исследуемый автомобиль, чтобы знать к какому сегменту сети Вы подключаетесь!

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

Реализации CAN на уровне электрических сигналов

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

1 ISO11898-2 или CAN-High Speed.

Классическая витая пара нагруженная с обоих концов резисторами 120 Ом.

В этом случае уровни на шине CAN выглядят так:

Для такой реализации сети используются как правило обычные CAN трансиверы в 8 выводном корпусе, аналоги PCA82C250, TJA1050 и им подобные. Работает такая конфигурация на скоростях 500 кбитс и выше. (Но могут быть исключения) .

2 ISO11898-3 или CAN-Low Speed или Faut Tolerant CAN

В этом варианте используется та же витая пара, но линии CAN-Low и CAN-High подтянуты к напряжению питания и массе соответственно.
Подробное описание FT-CAN по ссылке
Такой вариант CAN шины способен переключаться в однопроводный режим в случае повреждения одной из линий. Работает на скоростях до 250 кбитс.Уровни сигнала на шине отличаются от High Speed CAN, при этом не теряется возможность работы с шиной FT-CAN используя трансиверы High-Speed CAN и соблюдая ряд условий.
Подробнее в нашей статье о FT-CAN – ссылка.

Fault tolerant CAN обычно используется для низкоскоростного обмена между блоками управления относящимися к сегменту сети СалонКомфортМультимедиа.

ВАЖНО: При подключении к шине Faul tolerant CAN, подключать терминальный резистор 120 Ом между линиями CAN-High и CAN-Low НЕ НУЖНО !

3 Single Wire CAN или SW-CAN

Однопроводный вариант шины CAN. Работает на скорости 33.333 кбитс

Используется специальный тип трансиверов. Для того что бы подключиться к такому варианту шины CAN необходимо линию CAN-High анализатора подключить к шине SW-CAN а линию CAN-Low к массеземле.

CAN – шина, 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 шиной.

Идентификатор (11 – битный )

Или идентификатор (29 – битный)

от 0 до 8 байт данных в пакете

Идентификатор сообщения используется для идентификации данных, отправленных в этом пакете. Каждое отправленное сообщение принимается всеми узлами сети и в данном случае идентификатор позволяет понять конкретному устройству, необходимо ли обрабатывать данное сообщение. Максимальная длина сообщения 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.

Далее нужно подобрать соотношение между Tseg1 и Tseg2, которое даст нам желаемое положение точки выборки (Sample Point – SP).

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

Подставляем значения и получаем 16 * 0.7 = 11.2, что соответствует соотношению Tseg1 = 10, Tseg2 = 5, т.е. 1 + 10 + 5 = 16. Далее смотрим если Tseg2 >= 5, то SJW = 4, если Tseg2
Рисунок 6 – Настройка CAN фильтра

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


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

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

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

Читать еще:  ГАЗ Газель 274701; Зажигалка; › Бортжурнал › 55


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

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


Рисунок 10 – Поле Transmit

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

Итог

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

Протокол высокого уровня CANopen. Часть 1

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

В наше время насчитывается большое количество интерфейсов последовательной передачи данных. Некоторые из них, например, RS-232, USB, SPI, приобрели огромную популярность благодаря своим характеристикам или простоте использования. Другие же не нашли столь широкого распространения в электронных системах. К ним можно отнести IEEE 1394, RS-449, Х.21. Некоторые стандарты последовательных интерфейсов и вовсе быстро забывались после их разработки, чего нельзя сказать о стандарте CAN (Controller Area Network), разработанном в 1987 году немецкой компанией Robert Bosch GmbH и ставшим, пожалуй, самым популярным интерфейсом последовательной передачи данных в автомобильной отрасли и промышленном оборудовании. Благодаря высокой надежности, довольно высокой скорости передачи данных (до 1 МБ/с) и гибкости настройки и применения, этот интерфейс поддерживается множеством электронных устройств (промышленные контроллеры, микроконтроллеры, специализированные микросхемы, датчики). На сегодняшний день последней версией протокола является CAN 2.0b.

Стандарт CAN описывает поведение сигналов на низком уровне, причем в отрыве от физического уровня, то есть для передачи данных могут использоваться различные среды (медный кабель, оптоволокно и т.п.). Для ускорения проектирования сетей на основе CAN и стандартизации работы таких сетей был разработан протокол высокого уровня CANopen. Он получил широкое распространение в промышленном оборудовании, транспортных средствах, медицинском оборудовании, системах «умный дом». Этот протокол является открытым, и документация по его использованию доступна каждому. DS.301 представляет собой основной документ, в котором описаны основные положения и принципы работы CANopen. В связи с тем, что протокол ориентирован на использование в составе различных классов устройств, в документах CiA DS-4xx регламентируется работа CANopen в каждом из них. Так, например, CiA 412 относится к медицинскому оборудованию, а CiA 417 – к системам управления лифтами.

Топология сети CAN, принципы ее работы и форматы кадров подробно описаны в [1] и [2], поэтому не имеет смысла повторяться, а стоит перейти непосредственно к рассмотрению протокола высокого уровня CANopen на базе данной сети. На Рисунке 1 показана функциональная схема связи двух узлов с помощью шины CAN и протокола CANopen.

Рисунок 1.Коммуникационные уровни при соединении двух узлов.

Основной функциональной единицей протокола является объект. Под объектом может пониматься набор данных, несущих информацию о параметрах (например, показания датчика температуры), конфигурации узла или сети, возникших ошибках и т.п. Поэтому для устройства (узла) необходимым условием работы в сети является наличие словаря, представляющего собой группу доступных в определенном порядке объектов. По своей сути, словарь объектов – это связующее звено между приложением и передаваемой на физическом уровне информацией (Рисунок 2). С каждым устройством, использующим интерфейс CANopen, производитель должен предоставить файл с расширением *.eds (Electronic DataSheet), содержащий словарь объектов и дополнительную информацию.

Рисунок 2.Модель устройства с интерфейсом CANopen.

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

Каждый объект в словаре имеет 16-разрядный индекс и 8-разрядный подиндекс. С помощью них можно ссылаться на данный объект. В Таблице 1 показан пример описания идентификационного объекта, содержащего основную информацию об устройстве.

Протокол CANopen предполагает существование следующих типов объектов:

  • Сервисные объекты данных (SDO);
  • Объекты данных процесса (PDO);
  • Специальные функциональные объекты: объект синхронизации (SYNC), временная метка, срочное сообщение (EMCY);
  • Объекты управления сетью (NMT): NMT-сообщение, сообщение загрузки (boot-up), объект контроля ошибок.

SDO обеспечивают доступ к элементам словаря объектов, то есть, с помощью SDO можно читать и записывать информацию в словарь объектов. При связи посредством SDO между двумя устройствами устанавливается соединение типа «точка-точка», причем будет реализована клиент-серверная модель коммуникации, где устройство-клиент передает необходимое сообщение, а устройство-сервер выдает соответствующий этому сообщению ответ, в соответствии со схемой, изображенной на Рисунке 3.

Рисунок 3.Клиент-серверная модель.

При организации SDO-связи клиент с помощью мультиплексора, содержащего индекс и подиндекс объектного словаря, может предоставлять серверу определенный набор данных, которые будут передаваться. В основном передача SDO реализуется как сегмент-трансферт (segment transfer), при котором передается последовательность сегментов в количестве до 127. Непосредственно до передачи осуществляется стадия подготовки, когда клиент и сервер готовятся к обмену. Если необходимо передать объект размером до 4 байт, такой обмен может быть реализован на стадии инициализации, он также называется ускоренный трансферт (expedited transfer). Существует еще один тип передачи – блок-трансферт (block transfer). При этом передается набор блоков, каждый из которых состоит из 127 сегментов. Один сегмент содержит данные и свой порядковый номер в блоке. SDO описывается параметром связи, определяющим коммуникационные настройки SDO. Эти параметры связи расположены по специально отведенным адресам, и их индексы для SDO-сервера (SSDO) и SDO-клиента (CSDO) вычисляются по следующим правилам:

  • Индекс параметра связи SSDO = 1200h + № SSDO – 1;
  • Индекс параметра связи CSDO = 1280h + № CSDO – 1.
  • Сервисы, реализующие SDO-передачу, могут быть следующими:
  • Загрузка на SDO-сервер (download), состоящая из этапа инициализации загрузки и непосредственно загрузки сегментов;
  • Выгрузка с SDO-сервера (upload), состоящая из этапа инициализации выгрузки и непосредственно выгрузки сегментов;
  • Аварийное завершение передачи SDO.

Для непосредственной передачи полезных данных технологического процесса (температура, скорость, ток, напряжение и т.п.) в реальном времени используются PDO. Передача PDO осуществляется широковещательно, при этом применяется модель производитель-потребитель (producer-consumer), изображенная на Рисунке 4.

Рисунок 4.Модель производитель-потребитель.

В объектном словаре различаются два типа PDO – для передачи данных (TPDO) и для приема (RPDO). Устройства, в конкретный момент времени выдающие PDO на шину, называются производителями, а принимающие эти PDO – потребителями. PDO также описываются в объектном словаре устройства. Типы данных и отображение объектов в PDO описываются структурой, называемой PDO-отображение (PDO-mapping). С помощью SDO на стадии инициализации можно изменить количество PDO и отображение объектов внутри них. Все PDO описываются структурным параметром (или параметром отображения) и параметром связи, характеризующим коммуникационные возможности PDO. Индексы этих параметров определяются в соответствии со следующими правилами:

  • Индекс параметра связи RPDO = 1400h + № RPDO – 1;
  • Индекс параметра связи TPDO = 1800h + № TPDO – 1;
  • Индекс структурного параметра RPDO = 1600h + № RPDO – 1;
  • Индекс структурного параметра TPDO = 1A00h + № TPDO – 1.

С помощью одного PDO можно передать от 1 до 8 байт данных. В одной сети CANopen может присутствовать до 512 TPDO и до 512 RPDO.

PDO могут передаваться как синхронно, так и асинхронно относительно объекта синхронизации SYNC, выдающегося на шину с определенной периодичностью. Это проиллюстрировано Рисунком 5. Синхронные PDO передаются в рамках установленного интервала времени после появления на шине SYNC-объекта.

Рисунок 5.Принцип передачи синхронных и асинхронных PDO.

Асинхронные PDO передаются без какой-либо связи с объектом синхронизации. Различают также три режима вызова PDO (Рисунок 6):

  • По событию или по таймеру: механизм передачи PDO запускается после возникновения какого-либо внутреннего события или по срабатыванию таймера устройства;
  • По удаленному запросу: в этом случае устройство начинает передачу PDO после получения кадра удаленного запроса от другого устройства на шине;
  • Синхронная передача (цикличная или ацикличная): как уже отмечалось ранее, связана с появлением на шине SYNC-объекта.
Рисунок 6.Три режима вызова PDO.

Передача синхронных PDO может выполняться как в цикличном режиме, так и ацикличном. При выборе цикличного режима PDO передаются с определенной периодичностью, устанавливаемой числом от 1 до 240, т. е. 5 будет означать передачу PDO после каждого пятого появления SYNC-объекта на шине. В ацикличном режиме момент выдачи PDO на шину определяется внутренним событием устройства, но она обязательно должна выполняться в окне SYNC-объекта.

На Рисунке 7 показан принцип отображения PDO, основная идея которого заключается в том, что как производитель, так и потребитель PDO-сообщения должны знать, каким образом им необходимо интерпретировать содержимое этого сообщения. При этом PDO определяются по их идентификационным номерам (COB-ID). PDO-отображение описывает, какие переменные технологического процесса из поля данных PDO должны передаваться, каким образом они должны быть упорядочены, а также какой тип данных и какую длину они имеют. Таким образом, содержание и значение поля данных каждого определенного PDO определяется в виде записи PDO-отображения внутри словаря объектов на стороне производителя и на стороне потребителя.

Рисунок 7.Принцип отображения PDO.

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

Другими объектами, без которых немыслимо существование CANopen-сети, являются NMT-объекты, позволяющие управлять работой этой сети. Вначале стоит отметить, что в конкретный момент времени устройство должно находиться в одном из четырех состояний: инициализация (Initialization), готовность (Pre-operational), работа (Operational) или остановка (Stopped). При включении устройство проходит этап внутренней инициализации, и после ее успешного завершения переходит в состояние готовности. В этом состоянии уже возможно осуществить настройку CANopen-узла с помощью SDO. Затем узел может перейти в рабочее состояние. Для этого необходимо, чтобы Master сети (передача NMT сообщений происходит в соответствии с моделью Master-Slave) передал широковещательное сообщение Start_remote_node. ID NMT-сообщений равен 0, поскольку они должны иметь самый высокий приоритет в сети. В Таблице 2 представлено описание NMT-сообщений.

CAN протоколы высокого уровня

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

Основанная на базе протоколов высокого уровня CAN-технология успешно конкурирует на рынке распределенных систем автоматизации. Под терминами «CAN стандарт» или «CAN протокол» понимаются функциональные возможности, которые стандартизированы в ISO 11898. Этот стандарт объединяет физический уровень (Physical Layer) и уровень канала данных (Data Link Layer) в соответствии с 7-ми уровневой OSI моделью. Таким образом, «CAN стандарт» соответствует уровню сетевого интерфейса в 4-х уровневой модели TCP/IP. Однако, практическая реализация даже очень простых распределенных систем на базе CAN показывает, что помимо предоставляемых сервисов уровня канала данных требуются более широкие функциональные возможности : передача блоков данных длинной более чем 8 байтов, подтверждение пересылки данных, распределение идентификаторов, запуск сети и функции супервизора узлов. Так как эти дополнительные функциональные возможности непосредственно используются прикладным процессом, вводится понятие уровня приложений (Application Layer) и протоколов высокого уровня. Обычно их и называют термином «CAN протоколы».

OSI модель протоколов высокого уровня на базе CAN,протоколов TCP/IP

Для систем реального времени на базе CAN нет необходимости в реализации полной 7-ми уровневой модели OSI(рис. 1). Это связано с тем, что типичная CAN система имеет в своей основе единственный канал данных для обмена сообщениями между устройствами, все устройства ориентированы на конкретный способ передачи данных по каналу, а приложения пишутся именно под данную архитектуру сети и данный протокол. Поэтому нет необходимости в реализации уровня представлений, уровня сеанса и сетевого уровня из 7-ми уровневой модели OSI и были оставлены только 3 уровня этой модели : физический уровень, уровень канала данных и уровень приложений(рис. 2). Причем последний реализует некоторые функции транспортного уровня.

Из-за широко использования CAN сетей с различными целями и требованиями существуют несколько главных стандартов CAN-протоколов высокого уровня : CAL (CAN Application Layer), OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS (Smart Distribution Systems),CAN-Kingdom. Далее более подробно будет рассмотрен стандарт DeviceNet для сравнения с TCP/IP.

Основные возможности протоколов высокого уровня на базе CAN

Рассмотрим основные возможности, которые предоставляют протоколы высокого уровня:

  • система назначения идентификатора для сообщения
  • метод обмена данных процесса
  • прямая(peer-to-peer) связь
  • метод установления связей для обмена данных процесса
  • сетевое управление
  • модели и профайлы устройств

Метод назначения идентификатора сообщения является главным архитектурным элементом CAN систем, так как идентификатор CAN-сообщения определяет относительный приоритет сообщения и следовательно время обработки сообщения (latency time). Это также влияет на возможность применимости фильтрования сообщения,на использование возможных коммуникационных структур и эффективность использования идентификатора. Что касается назначения идентификаторов сообщений, существуют различные подходы для систем на базе CAN. Некоторые (CANopen) не применяют предопределение идентификаторов для общих структур системы, DeviceNet и SDS делают это.

Устройства (nodes) в DeviceNet получают постоянный идентификатор. Максимальное количество узлов составляет 64. Каждый узел имеет некоторое множество идентификаторов в одной из 3-х групп в зависимости от приоритета сообщения (рис. 3).

Группа 1 сообщений обеспечивает до 16 высоко приоритетных сообщений на устройство, группа 3 сообщений — до 7 низко приоритетных сообщений на устройство. Группа 2 сообщений предназначена для поддержки устройств с ограниченными способностями фильтрования сообщений. Поэтому для данной группы идентификаторов было выбрано фильтрование согласно номеру узла (MAC-ID). Это означает, что приоритет сообщений этой группы прямо определяется номером узла. MAC-ID группы 2 может быть адресом источника или адресом назначения.

DeviceNet использует также предопределенное Master/Slave множество связей для облегчения взаимодействия в Master/Slave системной конфигурации (рис. 4):

Поддерживаются следующие функции канала обмена I/O сообщениями и явными (Explicit) сообщениями между Master и Slave устройствами из предопределенного множества связей:

  • явный канал сообщений
  • изменение Master статуса канала (Master Poll Change of State/Cyclic channel)
  • изменение Slave статуса канала (Slave I/O Change of State/Cyclic channel )
  • Bit Strobe канал

Явный канал сообщений главным образом служит для конфигурации устройства. С изменением Master статуса канала Master может запрашивать данные ввода — вывода от устройства и посылать данные на Slave устройство. C изменением Slave статуса канала Slave устройство может передать данные Master-устройству. При помощи Bit Strobe команды Master-устройство может запросить данные у любого из 64 Slave устройств посредством одного сообщения.

Oбмен данных процесса

Передача данных процесса между устройствами распределенной системы — цель системы на основе CAN протокола. Поэтому передача прикладных данных (данные процесса, данные ввода — вывода) системы должна быть выполнена наиболее эффективным путем. CANopen и DeviceNet обеспечивают весьма схожие механизмы связи для передачи данных обслуживания / конфигурации процесса. У CANopen передача данных процесса происходит посредством так называемых «Объектов Данных Процесса (PDOs)», у DeviceNet посредством » I/O-сообщений «.

В таблице 1 приведены основные характеристики для протоколов CANopen, DeviceNet and SDS. Одним из главных различий является обеспечение протоколами DeviceNet and SDS фрагментации пакетов без подтверждения, что делает возможным передачу данных длиной более 8 байт. Также поддерживаются 3 различных протокола (рис. 4) по отношению к подтверждению приема данных («Transport Classes») . Например, классы 2 и 3 могут быть использованы для эффективного опроса(polling) устройств. Для той цели master устройство имеет коммуникационные объекты (connection objects), связанные с каждой командой опроса как клиентский транспортный класс 2 или 3. Каждое slave устройство имеет коммуникационные объекты серверного транспортного класса 2 или 3 для получения команд опроса и передачи соответствующих ответных данных.

Таблица 1. Exchange of Process Data in CANopen, DeviceNet and SDS (Multicasting)

CANopen
DeviceNet
SDS (V2.0)

Name of Communication Object
Process Data Object
I/O-Message
Multicast Channel APDU

Maximal Number of Communication Objects per Device
512 Transmit PDOs 512 Receive PDOs
27 I/O- Transmit Messages 1701 I/O Receive Messages per device 32 Multicast Channels for each of up to
32 Embedded Objects per device

Maximal length of Data Field
8 bytes
8 bytes fragmented: Arbitrary length
6 bytes fragmented: 64 * 4 bytes

Protocol
Unfragmented: No overhead, Notify/Read «Stored-Event»-protocol (CAL/CMS) Unacknowledged
Unfragmented: No overhead, three «Transport Classes» supported:

  • Unacknowledged,
  • Acknowledged by Server Connection Object,
  • Acknowledged by Application

Unfragmented: 2 byte protocol overhead, Unacknowledged
Fragmented: Unacknowledged fragmented protocol 1 byte protocol overhead per frame
Fragmented: Acknowledged fragmented protocol with Acknowledge after reception of complete block 4 bytes protocol overhead per fragment

Message Production Triggering Modes

  • On Request of local or remote application
  • Cyclic/acyclic synchron
  • Cyclic
  • Change-of-State
  • Application specific

Specified by object model

Mapping of Application Objects
Maximum number of mappable application objects/PDO dependent on data size of objects (1-bit objects: 64 application objects mappable) Definition of Application objects by means of «Mapping Parameter Record» (configurable) Dynamic mapping supported
Arbitrary number of Application objects mappable with fragmented protocol. Definition of Application objects by means of Assembly Object (several Assembly Objects possible) Dynamic mapping supported
Network Data Descriptor defines size, granularity and data type of I/O data of Embedded Object (V1.8)

Рис. 5. Device Net Transport Classes
Вызов (triggering) сообщений

Все рассматриваемые протоколы поддерживают различные способы вызова сообщений. DeviceNet поддерживает циклический (Cyclic), по состоянию (Change-of-State) и программный (Application) способы вызова. Циклический вызов осуществляется по истечению времени таймера и начинается передача сообщения. Передача по состоянию начинается, когда статус определенного объекта изменяется. В этом случае сообщение также передается, когда истекает определенный интервал времени, в котором не осуществлялась передача сообщения. Программным способом сам объект решает, когда начать передачу сообщения. В этом случае сообщение также передается, когда истекает определенный интервал времени без передачи сообщения.

Установление соответствий (mapping) для программных объектов

Сетевые устройства обычно содержат более одного программного объекта и передача I/O сообщения более чем одному программному объекту внутри одного PDO является необходимым требованием. В DeviceNet объединение прикладных данных осуществляется посредством трансляционных (assembly) объектов, которые определяют формат передаваемых данных. Устройство может содержать более одного I/O трансляционного объекта и выбор подходящего (consumed/ produced_connection_path) может быть настраиваемой опцией устройства.

Прямые (peer-to-peer) коммуникационные каналы

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

DeviceNet обеспечивает многоцелевые устройство ориентированные каналы и сервисы. Запись и чтение атрибутов объектов, контролирование объектов (reset, start, stop etc.), сохранение/восстановление атрибутов объектов осуществляется посредством явных (Explicit) сообщений. Намерение использовать данное сообщение определяется в поле данных CANа. На рис. 7 показан формат поля данных фрагментированного Explicit сообщения. В запросе сервиса указывается номер класса, номер экземпляра(instance), номер атрибута (в поле Service specific arguments).

Рис. 6. DeviceNet Fragemented Explicit Message Data Field Format (Request/Response)

Explicit(прямая) связь устанавливается посредством менеджера сообщений (Unconnected Message Manager (UCMM)). UCMM предоставляет два сервиса для открывания и закрывания подобных соединений. Каждое устройство, поддерживающее UCMM, резервирует у себя идентификаторы сообщений для запросов и ответов для UCMM. Для устройств 2-й группы, которые не поддерживают UCMM порт, master устройство сперва должно разместить Explicit соединение в предопределенном множестве соединений. Запрос к устройству группы 2 передается как Explicit запрос без предварительного установления соединения (Unconnected Explicit Request ) с зарезервированным идентификатором сообщения.

Сравнительные характеристики протоколов CANopen, DeviceNet и SDS в отношении прямых (peer-to-peer) коммуникационных каналов представлены в таблице 2.

Таблица 2. Main Characteristics of Peer-to-Peer Communication Channels

CANopen
DeviceNet
SDS (V2.0)

Name
Service Data Channel
Explicit Message
Peer-to-peer Channel

Maximum number of channels
128 Client SDOs, 128 Server SDOs per device
27 Explicit Transmit Messages 1701 Explicit Receive messages per device
4 channels per Embedded Object. 32 Embedded Objects per Logical Device

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

Канальный уровень полностью определяется спецификацией CAN. Он делится на 2 подуровня — MAC (Media Access Control) и LLC (Logical Link Control).

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

Подуровень управления контролем доступа к среде (MAC), представляет нижние компоненты канального уровня ISO/OSI. MAC включает в себя правила и функции, относящиеся к инкапсуляции/декапсуляции, обнаружению ошибок и выдаче сигналов.

Кадры

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

В CAN используются четыре типа кадров:

1. Кадр данных (data frame):

Наиболее часто используемый тип сообщения. Он состоит из следующих основных частей (рис. 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) — содержит информацию о кадре и состоит из:

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

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

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

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

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

o cлот подтверждения (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 кадры, в том числе кадры ошибки и перегрузки, отделяются от предыдущих кадров межкадровым промежутком. Он формируется тремя рецессивными битами.

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector