CAN интерфейс

(Control Area Network)

CAN (Control Area Network) - последовательная магистраль, обеспечивающая увязку в
сеть "интеллектуальных" устройств ввода/вывода, датчиков и исполнительных устройств
некоторого механизма или даже предприятия. Характеризуется протоколом,
обеспечивающим возможность нахождения на магистрали нескольких ведущих устройств,
обеспечивающим передачу данных в реальном масштабе времени и коррекцию ошибок,
высокой омехоустойчивостью. Система CAN обеспечена большим количеством
микросхем, обеспечивающих работу подключенных к магистрали устройств, разработку
которых начинала фирма BOSH для использования в автомобилях, и в настоящее время
широко используемых в автоматизации промышленности. Цеколѐвка разема приведена на
рисунке.

Стандарт ISO 11898

Скорость передачи
Расстояние передачи
Характер сигнала, линия передачи
Количество драйверов
Количество приемников
Схема соединения
1 Мбит/с (максимум)
1000 м (максимум)
дифференциальное напряжение, скрученная пара
64
64
полудуплекс, многоточечная

Предназначен для организации высоконадежных недорогих каналов связи в

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

Расстояние, м 25 50 100 250 500 1000 2500 5000

Скорость, Кбит/с 1000 800 500 250 125 50 20 10
 Максимальное число абонентов, подключенных к данному интерфейсу фактически
определяется нагрузочной способностью примененных приемопередатчиков.
Например, при использовании трансивера фирмы PHILIPS PCA82C250 она равна
110.
Протокол CAN использует оригинальную систему адресации сообщений. Каждое
сообщение снабжается идентификатором, который определяет назначение
передаваемых данных, но не адрес приемника. Любой приемник может
реагировать как на один идентификатор, так и на несколько. На один
идентификатор могут реагировать несколько приемников.
Протокол CAN обладает развитой системой обнаружения и сигнализации ошибок.
Для этих целей используется поразрядный контроль, прямое заполнение битового
потока, проверка пакета сообщения CRC-полиномом, контроль формы пакета
сообщений, подтверждение правильного приема пакета данных. Хемминговый
интервал d=6. Общая вероятность необнаруженной ошибки 4.7x10-11.
Система арбитража протокола CAN исключает потерю информации и времени при
"столкновениях" на шине.
Интерфейс с применением протокола CAN легко адаптируется к физической среде
передачи информации. Это может быть дифференциальный сигнал, оптоволокно,
просто открытый коллектор и т.п. Несложно делается гальваническая развязка.
Элементная база, поддерживающая CAN, широко выпускается в индустриальном
исполнении.

CAN 2.0 А
1. Введение

CAN (Controller Area Network) - это последовательный протокол связи с эффективной

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

Протокол CAN можно разделить на следующие уровни:

объектный уровень
канальный уровень
физический уровень

Объектный и канальный уровни включают весь сервис и функции передачи данных

определяемых ISO/OSI моделью. Область объектного уровня включает:

Поиск сообщений для передачи.

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

Объектный уровень можно реализовывать различными способами.

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

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

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

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

2. Основные характеристики протокола

каждое сообщение имеет определенный приоритет

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

Сообщения

Информация по шине посылается в фиксированном формате сообщений различной, но

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

Информационная маршрутизация

В CAN нет ни какой информации относительно конфигурации сети (например, адреса

узла). Это имеет несколько важных следствий:

Гибкость системы:

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

Маршрутизация сообщений:

Содержание сообщения определяется идентификатором. Идентификатор не указывает

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

Передача группе:

Как следует из фильтрации сообщений, любое число узлов может одновременно

получать и реагировать на одно и тоже сообщение.

Непротиворечивость данных:

Внутри сети CAN гарантировано, что сообщение принято всеми узлами или ни одним
узлом.

Скорость передачи информации

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

Приоритеты

Идентификатор и RTR - бит определяют статический приоритет сообщения в течение

доступа к шине.

Удаленный запрос данных

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

Multimaster

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

Арбитраж

Когда шина свободна, любой узел может начать передачу сообщения. Если два или
больше узла начинают передавать сообщения в одно и тоже время, конфликт при доступе
к шине будет решен поразрядным арбитражем используя идентификатор и RTR - бит.
Механизм арбитража гарантирует, что ни время, ни информация не будут потеряны. Если
кадр данных и кадр удаленного запроса данных начинают передаваться в одно время, то
кадр данных имеет более высокий приоритет, чем кадр удаленного запроса данных. В
течение арбитража каждый передатчик сравнивает уровень переданного бита с уровнем,
считываемым с шины. Если эти уровни одинаковы, узел может продолжать посылать
данные дальше. Если был послан уровень лог. '1' (recessive), а с шины считан уровень лог.
'0' (dominant), то узел теряет право дальнейшей передачи данных и должен прекратить
посылку данных на шину.

Безопасность

Чтобы достичь высокой безопасности передачи данных, приняты мощные меры

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

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

Для обнаружения ошибок приняты следующие меры:

текущий контроль (передатчики сравнивают уровни битов, которые переданы, с

уровнями на шине).
побитовое заполнение
проверка кадра сообщения

Эффективность обнаружения ошибок

 Механизмы обнаружения ошибок имеют следующие возможности:

обнаружение всех глобальных ошибок

обнаружение всех локальных ошибок передатчиков
обнаружение до 5 случайно распределѐнных ошибок в сообщении
обнаружение последовательной группы ошибок длиной до 15
обнаружение любого числа нечетных ошибок в сообщении

Общая остаточная вероятность ошибки для необнаруженных, разрушенных сообщений,

меньше чем:

скорость появления ошибки * 4.7*10Е-11

Сигнализация ошибки и время восстановления

Разрушенные сообщения помечаются узлом, обнаружившим ошибку. Такие сообщения

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

Типизация ошибок

Узлы CAN способны отличить временные ошибки от постоянных отказов. Дефектные

узлы будут отключены.

Соединения

Линия связи по протоколу CAN - это шина, к которой может быть подключѐн ряд узлов.
Количество узлов не имеет никакого теоретического предела. Фактически количество
узлов будет ограничено временами задержек и/или электрической нагрузкой на линии
шины. Способ, которым выполнена шина, не установлен в данной спецификации.
Например, это может быть одиночный провод (+земля), два дифференциальных провода,
оптическое стекловолокно.

Уровни шины

Шина может принимать одно из дополняющих друг друга значений: "dominant" и

"recessive". В случае одновременной подачи "dominant" бита и "recessive" бита,
возникающее в результате значение шины будет "dominant".
(Прим. переводчика: далее считается что "recessive" = лог. "1", а "dominant" = "0").

Подтверждение

Все приѐмники проверяют непротиворечивость принимаемого сообщения и

подтверждают непротиворечивое сообщение.

Режим "сна" / пробуждения

Чтобы уменьшить потребляемую мощность системы, узел CAN может быть переведен в
режим "сна". Режим "сна" заканчивается при любом действии на шине или внутреннем
состоянии системы. При пробуждении запускается внутренняя синхронизация, канальный
уровень ждѐт стабилизации генератора системы, а затем будет ожидать
самосинхронизации к действиям на шине (синхронизация к действиям на шине
заканчивается после принятия последовательности 11 битов с лог. "1"). Для пробуждения
узла из режима покоя может использоваться некоторое сообщение пробуждения со
специальным идентификатором.

3. Передача сообщений

При передаче информации с помощью протокола CAN используется четыре типа

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

3.1 Кадр данных (DATA FRAME)

Кадр данных состоит из 7 различных полей: "Начало кадра", "поле арбитража", "поле
контроля", "поле данных", "поле CRC", "поле подтверждения", "конец кадра".

Начало кадра (Start of Frame)

 Отмечает начало кадра данных или кадра удаленного запроса данных. Состоит из бита с
лог. '0'.
Узлу разрешено начинать передачу только при свободной шине (см. простой шины). Все
узлы должны быть синхронизированы по началу фронта, вызванного полем "начало
кадра" (см. аппаратная синхронизация) узла, начавшего работу первым.

Поле арбитража (Arbitration Field)

Состоит из идентификатора и RTR-бита.

Идентификатор (Identifier)

Имеет длину 11 бит. Эти биты должны быть переданы в порядке от ID10 до ID4. Самый
старший бит ID0. 7 старших битов не должны быть все битами с лог '1'.

RTR-бит (RTR - bit)

Бит запроса передачи.

В кадре данных RTR-бит - "0". Внутри кадра удаленного запроса данных - "1".

Поле контроля (CONTROL FIELD)

Включает 6 бит. Это - код длины данных (4бита) и 2 бита зарезервированные под
будущие расширения. Зарезервированные биты должны быть "0".

Код длины данных (DLC)

Показывает количество байт в поле данных. Код длины данных имеет размер 4 бита и
передаѐтся внутри контрольного поля.
Допустимые значения: 0.......8.
Другие значения использоваться не могут.

Поле данных (DATA FIELD)

Включает данные, передаваемые внутри кадра данных. Оно может содержать от 0 до 8

байт, каждый из которых содержит 8 бит.

CRC поле (CRC FIELD)

Содержит CRC - последовательность, сопровождаемую разделителем

CRC-последовательность (CRC Sequence):

Для вычисления CRC полинома, полином, коэффициенты которого задаются потоком,

состоящим из значений, бит полей: "начало кадра ", "поле арбитража", "поле контроля",
"поле данных" (если имеется) (самые младшие 15 коэффициентов полинома =0), должен
быть разделѐн полином следующего вида:
x^15+x^14+x^10+x^8+x^7+x^4+x^3+1
Остаток этого полиномиального деления есть CRC-последовательность, передаваемая по
шине.

CRC-разделитель (CRC Delimiter):

CRC-последовательность сопровождается CRC-разделителем, который всегда равен

лог. "1".

Поле подтверждения (ACK FIELD)

Длина 2 бита. Содержит область подтверждения (1 бит) и разделитель подтверждения

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

Область подтверждения (ACK Slot)

 Все узлы, получившие соответствующую CRC-последовательность, сообщают об этом
внутри области подтверждения перезаписью бита с лог. "1" на бит с лог. "0".

Разделитель подтверждения (ACK Delimiter)

Второй бит области подтверждения должен быть - лог. "1". Следовательно, область
подтверждения окружена битами с лог. "1" (CRC-разделитель и разделитель
подтверждения).

Конец кадра (END OF FRAME)

Каждый кадр данных и кадр удаленного запроса данных разграничены

последовательностью флагов, состоящей из семи битов с лог. "1".

3.2 Кадр удаленного запроса данных (REMOTE FRAME)

Узел может инициализировать передачу кадра данных другим узлом, посылая кадр
удаленного запроса данных.
Этот кадр состоит из 6 полей:
"Начало кадра", "поле арбитража", "поле контроля", "поле CRC", "поле подтверждения",
"конец кадра".
В отличие от кадра данных , RTR бит = "1". Здесь нет поля данных, зависящего от
значения "кода длины данных", внутри этого поля может быть записано любое из
допустимых значений (0…….8).
Полярность RTR бита показывает, является ли передаваемый кадр кадром данных или
кадром удаленного запроса данных

3.3. Кадр ошибки (ERROR FRAME)

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

Для корректного завершения кадра ошибки, узлу в состоянии "пассивной ошибки"

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

Флаг ошибки (Error Flag):

Существует 2 формы флага ошибки: активный и пассивный флаг ошибки.

 1. активный флаг ошибки состоит из 6 последовательных бит с лог. "0".
2. пассивный флаг ошибки состоит из 6 последовательных бит с лог. "1, если они не
перезаписаны битами с лог. "0" других узлов.
Узел в состоянии "активной ошибки" при обнаружении ошибки передает активный флаг
ошибки. Форма флага ошибки нарушает закон кодирования битового потока методом
разрядного заполнения (см. раздел "Кодирование битового потока"). Вследствие этого все
узлы обнаруживают условие ошибки и начинают передавать флаг ошибки. В результате,
последовательность бит с лог. "0", контролируемая на шине является суперпозицией
флагов ошибок отдельных узлов. Общая длина этой последовательности - от 6 до 12 бит с
лог. "0".
Узел в состоянии "пассивной ошибки" при обнаружении ошибки передает пассивный
флаг ошибки, он ждет последовательности из 6 одинаковых бит, определяющих начало
флага пассивной ошибки. Когда эта последовательность будет обнаружена, флаг
пассивной ошибки будет завершен.

Разделитель ошибки (Error Delimiter)

Разделитель ошибки состоит из 8 бит с лог. "1". После передачи флага ошибки каждый
узел посылает биты с лог. "1" и контролирует шину, пока не обнаружит бит с лог. "1".
Впоследствии он начинает передавать 7 бит с лог. "1".

3.4. Кадр перегрузки (OVERLOAD FRAME)

Кадр перегрузки содержит два битовых поля: флаг перегрузки и разделитель

перегрузки.

Имеются два вида перегрузки, которые оба приводят к передаче кадра перегрузки.
1. Внутреннее состояние приѐмника, которое требует задержки следующего кадра
данных или кадра удаленного запроса данных.
2. Обнаружение бита с лог. "0" в течение поля перерыва (см. межкадровое
пространство).
Передача кадра перегрузки из-за состояния 1 возможна только в первом битовом
интервале перерыва, в то время как кадры перегрузки по состоянию 2 начинают
передаваться на следующем битовом интервале после обнаружения бита с лог. "0".
Для больших задержек может быть послано несколько кадров перегрузки.

Флаг перегрузки (Overload flag)

Состоит из 6 бит с лог. "0". Формат соответствует активному флагу ошибки.

Форма флага перегрузки нарушает фиксированную форму поля перерыва. Поэтому,
другие узлы также обнаруживают состояние перегрузки и в свою очередь начинают
передавать флаг перегрузки.
В случае обнаружения бита с лог. "0" в течение третьего бита перерыва, некоторые узлы
не будут корректно интерпретировать флаг перегрузки, первый (из шести) бит с лог. "0"
будет принят за поле "начало кадра". Шестой бит флага перегрузки с лог. "0" нарушает
закон кодирования битового потока методом разрядного заполнения (см. раздел
"Кодирование битового потока методом разрядного заполнения").

Разделитель перегрузки (Overload Delimiter)

Состоит из 8 бит с лог. "1".

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

4. Межкадровое пространство (INTERFRAME SPACE)

Кадры данных и кадры удаленного запроса данных отделяются от предшествующих

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

Кадрам перегрузки и кадрам ошибки не предшествует межкадровое пространство;

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

Поле перерыва (Intermission)

Состоит из 3 бит с лог. "1". В течение перерыва никакому узлу нельзя начинать
передачу кадра данных или кадра удаленного запроса данных. Единственно возможное
действие - это сигнализация состояния перегрузки.
 Простой шины (Bus Idle)

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

Обнаружение бита с лог. "0" на шине в течение этого поля интерпретируется как поле
"начало кадра".

Приостановка передачи

Узел в состоянии "пассивной ошибки", после передачи сообщения, посылает 8 бит с

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

5. Определение передатчика / приемника

Передатчик

Узел, передающий сообщение называется передатчиком этого сообщения. Узел

является передатчиком до тех пор, пока он не потерял арбитраж.

Приѐмник

Узел называется приѐмником сообщения, если он не передатчик сообщения и шина

занята.

6. Корректность сообщения

Точка времени, в которой сообщение является корректным, различна для передатчиков

и приѐмников сообщений.

Передатчик

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

Приѐмник

Сообщение корректно для приѐмника, если нет ошибок до конца кадра.

7. Кодирование битового потока

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

8. Обработка ошибок

Существует пять типов не взаимоисключающих ошибок:

разрядная ошибка

Узел, который посылает что - либо на шину также контролирует шину.

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

ошибка заполнения

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

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

ошибка CRC

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

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

ошибка формата

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

формата содержит один или несколько лишних бит.

ошибка подтверждения

Ошибка подтверждения обнаруживается передатчиком всякий раз, когда нет

контроля бита с лог. "0" в течение области подтверждения.

9. Сигнализация ошибок

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

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

10. Типизация ошибок

Узел может быть в одном из трех состояний:

активной ошибки
пассивной ошибки
отключения от шины

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

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

Узел находится в состоянии "пассивной ошибки", если счетчик ошибок передачи и /

или счетчик ошибок приема больше или равен 128.
Узел отключается от шины, если счетчик ошибок передачи или приема больше или
равен 256.
Узел, находившиеся в состоянии "пассивной ошибки" переходит в состояние "активной
ошибки", если счетчик ошибок передачи и счетчик ошибок приема меньше или равен 127.
Узлу, который находится в состоянии "отключения от шины", разрешается перейти в
состояние "активной ошибки", с установкой обоих счетчиков в 0, после того, как на шине
будут проконтролированы 128 прохождений 11 последовательных битов с лог. "1".

Обратите внимание:
1. Величина счетчика ошибки большая, чем 96 указывает на серьезные нарушения на
шине. Это можно использовать для проверки состояния шины.
2. Запуск / Пробуждение:
Если в некоторый момент времени активен только один узел, и если этот узел передает
некоторое сообщение, он не получит подтверждения, обнаруживается ошибка и
происходит повтор сообщения. Из-за этого он может перейти в состояние "пассивной
ошибки", но не может перейти в состояние "отключения от шины".

10. Требования к синхронизации

Номинальная скорость передачи информации в битах

Номинальная скорость передачи информации в битах - число битов за секунду,

передаваемое в отсутствии пересинхронизации идеальным передатчиком.
 Номинальное время передачи бита
номинальное время передачи бита = 1 / номинальную скорость передачи информации
Номинальное время передачи бита можно представить как время, разделенное на
отдельные не перекрывающиеся сегменты времени. Это сегменты:
- Сегмент синхронизации (SYNC_SEG)
- Сегмент времени распространения (PROP_SEG)
- Сегмент TSEG1 (PHASE_SEG1)
- Сегмент TSEG2 (PHASE_SEG2)

SYNC SEG

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

узлы на шине. Ожидается, что фронт сигнала находится внутри этого сегмента.

PROP SEG

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

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

TSEG1 и TSEG2.

Эти сегменты используются, чтобы компенсировать ошибки смещения фазы сигнала.

Эти сегменты могут быть удлинены или укорочены пересинхронизацией.

Точка считывания (Sample point)

Точка считывания - точка времени, в которой уровень шины читается и

интерпретируется, как величина соответствующего бита. Ее место - в конце TSEG1.

Время обработки информации

Время обработки информации - отрезок времени, начинающийся с точки считывания,

зарезервированный для вычисления уровня бита.

Квант времени

Квант времени - фиксированная единица времени, полученная из периода генератора.

Существует программируемый делитель, оперирующий целочисленными величинами,
изменяющимися, по крайней мере, от 1 до 32. Начиная с минимального кванта времени,
квант времени может иметь длительность:
квант времени = m * минимальный квант времени ,где m - величина делителя.
минимальный квант времени = 1 / f генератора.

Длительность отрезков времени

SYNC_SEG - 1 квант времени .

PROP_SEG - программируем, 1,2, ..., 8 квантов.
TSEG1 - программируем, 1,2, ..., 8 квантов.
TSEG2 - максимум из TSEG1 и времени обработки информации
время обработки информации - меньше или равно 2 квантам.

12. Синхронизация

Аппаратная синхронизация

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

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

Ширина перехода пересинхронизации

В результате пересинхронизации TSEG1 может быть удлинен, или TSEG2 может быть
сокращен. Количество удлинения или сокращения сегментов TSEGx (x=1,2) имеет
верхний предел, связанный с шириной перехода пересинхронизации. Ширина перехода
пересинхронизации должна быть программируема между 1 и min(4, TSEG1).
Синхронизация информации может быть получена из переходов от одного бита к
другому. Максимальная длина между двумя переходами, которые могут использоваться
для пересинхронизации - 29 времен передачи бита.

Фазовая ошибка фронта Фазовая ошибка фронта определяется позицией фронта

относительно SYNC_SEG, измеряется в квантах времени. Знак фазовой ошибки
определяется следующим образом:

e = 0, если фронт сигнала находится внутри SYNC_SEG.

e> 0, если фронт сигнала перед точкой считывания.
e < 0, если фронт сигнала после точки считывания предыдущего бита.

Пересинхронизация Эффект пересинхронизации - также как и от аппаратной

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

и если ошибка фазы положительна, то TSEG1 удлиняется на время равное:

время передачи бита * ширину перехода пересинхронизации.
и если ошибка фазы отрицательна, то TSEG2 - сокращается на время равное:
время передачи бита * ширину перехода пересинхронизации.

Правила синхронизации Синхронизация и пересинхронизация - две формы

синхронизации. На них действуют следующие правила:
1. Позволяется только одна синхронизация внутри одного интервала передачи бита.
 2. Для синхронизации будет использоваться фронт только, если величина, полученная в
предыдущей точке считывания (предыдущая величина на шине) отличается от величины
на шине сразу после фронта.
3. Синхронизация выполняется всякий раз, по фронту "1" -> "0" в течение простоя
шины.
4. Все другие фронты "1" -> "0" (и фронты "0" -> "1" в случае низких скоростей),
выполняемые по правилам 1 и 2, будут использоваться для пересинхронизации.

CAN 2.0 В
1. Введение

CAN - последовательный протокол связи, который эффективно поддерживает

распределенное управление в реальном масштабе времени с высоким уровнем
безопасности.

Область применения - от высокоскоростных сетей до дешевых мультиплексных шин. В

автоматике, устройствах управления, датчиках используется CAN со скоростью до 1
Mbit/s.

Задача данной спецификации состоит в том, чтобы достигнуть совместимости между

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

Уровень передачи данных (Data Link Layer)

Подуровень логического управления линией (LLC)
Подуровень управления доступом к среде передачи (MAC)
Физический Уровень (Physical Layer)

Обратите внимание, что в предыдущих версиях спецификации CAN функции LLC и

MAC подуровней, уровня передачи данных, были описаны в уровнях, обозначенных как
'объектный уровень ' и 'канальный уровень'.

Область LLC подуровня:

обеспечение сервиса для передачи данных и для удалѐнного запроса данных.

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

Внутри одной сети, физический уровень одинаков для всех узлов.

Однако существует свобода в выборе физического уровня. Цель этой спецификации -
определить MAC подуровень и небольшую часть LLC подуровня уровня передачи
данных и описать действие протокола CAN на окружающие уровни

2. Основные характеристики

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

Послойная архитектура CAN - сети согласно модели OSI

Физический уровень определяет, как сигналы фактически передаются и,

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

Информация на шине представлена в виде фиксированных сообщений различной, но

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

Информационная маршрутизация

В системах CAN, нет никакой информации относительно конфигурации системы

(например, адрес узла). Это имеет несколько важных следствий:

Гибкость системы:
Узлы могут быть добавлены к CAN - сети без изменения программного обеспечения и
аппаратных средствах любого узла или прикладного уровня.

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

Групповая обработка:
 Любое число узлов может получать и одновременно воздействовать на одно и то же
сообщение.

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

Скорость передачи информации в битах

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

Приоритеты

Идентификатор определяет статический приоритет сообщения в течение доступа к

шине.

Удаленный запрос данных

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

Multimaster

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

Арбитраж

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

Безопасность

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

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

Для обнаружения ошибок применяются следующие меры:

Текущий контроль (передатчики сравнивают уровни передающихся битов с уровнями,
обнаруженными на шине)
Циклический контроль по избыточности
Контроль кадра сообщения

Эффективность обнаружения ошибок

Механизмы обнаружения ошибок позволяют обнаруживать:
- все ошибки глобального характера
- все локальные ошибки передатчика
- до 5 случайных ошибок в сообщении
- последовательную группу ошибок длиной до 15
- любые ошибки нечетности.
Общая остаточная вероятность ошибки для необнаруженных искаженных сообщений
меньше чем: частота ошибки сообщения * 4.7* 10 Е-11

Сигнализация ошибки и время восстановления

Искаженные кадры помечаются любым узлом, обнаружившим ошибку. Такие кадры

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

Типизация ошибок

Узлы CAN способны отличить короткие неполадки от постоянных отказов. Дефектные

узлы отключаются.

Подключение

Последовательная линия связи CAN является шиной, к которой теоретически может

быть подключено любое количество узлов. Фактически общее число узлов будет
ограничено временной задержкой и (или) электрической нагрузкой на линии шины.

Канал обмена

Шина состоит из канала обмена, который передаѐт биты. Из этих данных может быть
получена информация о пересинхронизации. Способ, по которому этот реализуется канал
обмена, в этой спецификации не устанавливается. Например, это может быть одно-
проволочный провод (плюс земля), два дифференциальных провода, оптическое
стекловолокно.

Уровни сигналов

Шина может иметь одно из двух логических значений: 'dominant' или 'recessive'. При
одновременной передаче 'dominant' и 'recessive' битов, возникающая в результате
величина на шине будет 'dominant'. Физические состояния (например, электрическое
напряжение, свет), которые представляют логические уровни, не даны в этой
спецификации. (прим. переводчика: далее считается, что "dominant" уровень
эквивалентен нулевому уровню, а "recessive" уровень эквивалентен единичному уровню).

Подтверждение

Все приемники проверяют непротиворечивость получаемого сообщения,

подтверждают непротиворечивость сообщения и помечают противоречивые сообщения.

Режим "сна" / пробуждения

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

Генератор

Требования к синхронизации позволяют использовать керамические резонаторы в

системах со скоростями передачи до 125kbit/s. Для более высокой скорости шины CAN,
требуется кварцевый резонатор.

3. Передача сообщений

Форматы кадров
Имеются два формата, которые отличаются по длине поля идентификатора:

Кадры с 11-разрядным идентификатором - называются стандартными кадрами.

Кадры, содержащие 29 разрядные идентификаторы, называются расширенными
кадрами.

Типы кадров

Кадр данных передает данные от передатчика приемнику. Кадр удаленного запроса

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

Кадр данных (Data frame)

Кадр данных состоит из семи различных полей:

"Начало кадра" (start of frame), "поле арбитража" (arbitration field), "поле управления"
(control field), "поле данных" (data field), "поле CRC" (CRC field), "поле подтверждения"
(ACK field), "конец кадра" (end of frame). Поле данных может иметь нулевую длину.
 Начало кадра (стандартный или расширенный формат) (Start of frame)

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

Поле арбитража (Arbitration field)

Формат поля арбитража отличается для стандартного и расширенного форматов.

- в стандартном формате поле арбитража, состоит из 11 разрядного
идентификатора и RTR-бита. Биты идентификатора обозначены
ID-28 ... ID-18.
- в расширенном формате поле арбитража состоит из 29 разрядного
идентификатора, SRR-бита, IDE-бита, и RTR-бита. Биты
идентификатора обозначены ID-28 ... ID-0.
Чтобы отличать стандартный формат и расширенный формат, зарезервированный в
предыдущих спецификациях CAN (версия 1.0-1.2) бит r0 теперь обозначен как IDE бит.
 Идентификатор

Идентификатор - стандартный формат

Длина идентификатора - 11 бит и соответствует BASE ID в расширенном формате. Эти
биты передаются в порядке ID-28 … ID-18. Самый младший бит - ID-18. 7 старших битов
(ID-28 - ID-22) не должны быть все единичными битами.

Идентификатор - расширенный формат

В отличие от стандартного идентификатора, расширенный идентификатор состоит из 29
бит. Его формат содержит две секции:
1. Base ID - 11 бит
2. Extended ID - 18 бит

Base ID

Base ID состоит из 11 бит. Эта секция передается в порядке от ID-28 до ID-18. Это
эквивалентно формату стандартного идентификатора. Base ID определяет базовый
приоритет расширенного кадра.

Extended ID

Extended ID состоит из 18 бит. Эта секция передается в порядке от ID-17 до ID-0. В

стандартном кадре идентификатор сопровождается RTR битом.

Бит RTR (стандартный и расширенный формат)

Бит запроса удаленной передачи.

В кадрах данных RTR бит должен быть передан нулевым уровнем. Внутри кадра
удаленного запроса данных RTR бит должен быть единичным.
В расширенном кадре сначала передается Base ID , с последующими битами IDE и SRR.
Extended ID передается после SRR бита.

Бит SRR (расширенный формат)

Заменитель бита удаленного запроса.

SRR - единичный бит. Он передается в расширенных кадрах в позиции RTR бита. Таким
образом, он заменяет RTR - бит стандартного кадра.
Следовательно, при одновременной передаче стандартного кадра и расширенного кадра,
Base ID которого совпадает с идентификатором стандартного кадра, стандартный кадр
преобладает над расширенным кадром.

Бит IDE (расширенный формат)

Бит расширения идентификатора

IDE Бит принадлежит:
- Полю арбитража для расширенного формата
- Полю управления для стандартного формата
IDE бит в стандартном формате передается нулевым уровнем, в то время как в
расширенном формате IDE бит - единичный уровень.

Поле управления (стандартный формат и расширенный формат)

(Control field)

Поле управления состоит из шести бит. Формат поля управления отличается для
стандартного и расширенного формата. Кадры в стандартном формате включают: код
длины данных (DLC), бит IDE, который передается нулевым уровнем (см. выше), и
зарезервированный бит r0.
Кадры в расширенном формате включают код длины данных и два зарезервированных
бита r1 и r0. Зарезервированные биты должны быть посланы нулевым уровнем, но
приемники принимают единичные и нулевые уровни биты во всех комбинациях.

Код длины данных (стандартный и расширенный форматы)

(Data length code)

Число байт в поле данных обозначается кодом длины данных. Этот код длины данных,
размером 4 бита, передается внутри поля управления.
Допустимое число байт данных: {0,1, ...., 7,8}.
Другие величины использоваться не могут.

Поле данных (стандартный и расширенный форматы)

(Data field)

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

Поле CRC (стандартный и расширенный форматы)

(CRC field)
Содержит последовательность CRC и CRC - разделитель.

Последовательность CRC (стандартный и расширенный форматы)

(CRC Sequence)
 Последовательность контроля кадра, получаемая из избыточного циклического кода,
лучше всего подходит для кадров с числом битом меньше чем 127 бит.
При вычислении CRC, полином разделяется и определяется как полином, коэффициенты
которого заданы последовательностью бит, состоящей из полей: "начало кадра", "поле
арбитража", "управляющее поле", "поле данных" (если есть) и, для 15 самых младших
коэффициентов, 0. Этот полином разделен на полином:
X ^15 + X ^14 + X ^10 + X ^8 + X^ 7 + X^4 + X^3 + 1.
Остаток от этого полиномиального деления и есть последовательность CRC,
передаваемая по шине.

Разделитель CRC (стандартный формат, а также расширенный формат)

(CRC Delimiter)

Последовательность CRC сопровождается разделителем CRC, который состоит из

одного единичного бита.

Поле подтверждения (стандартный формат и расширенный формат)

(ACK field)

Поле подтверждения имеет длину два бита и содержит: "область подтверждения" и

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

Область подтверждения (ACK slot)

Все узлы, получившие соответствующую последовательность CRC, сообщают об этом

во время приема поля "область подтверждения" путем замены бита с единичным уровнем
на бит с нулевым уровнем.

Разделитель подтверждения (ACK delimiter):

Разделитель подтверждения - второй бит поля подтверждения, и он должен быть

представлен единичным уровнем.

Конец кадра (стандартный формат и расширенный формат)

(End of frame)

Каждый кадр данных и кадр удаленного запроса данных ограничен

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

Кадр удаленного запроса данных (Remote frame)

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

соответственных данных исходными узлами, посылая кадр удаленного запроса данных.
Кадр удаленного запроса данных существует и в стандартном формате и расширенном
формате. В обоих случаях он состоит из шести битовых полей:
"начало кадра" (Start of frame), "поле арбитража" (Arbitration field), "управляющее поле"
(Control field), "поле CRC" (CRC - field), "поле подтверждения" (ACK field), "конец
кадра" (End of frame).
В отличие от кадра данных, RTR бит кадра удаленного запроса данных - единичный. В
этом кадре отсутствует поле данных. При этом значение кода длины данных может
принимать любое значение в пределах допустимого диапазона [0,8]. Значение кода
длины данных соответствует коду длины данных кадра данных. RTR бит указывает,
является ли переданный кадр кадром данных.

Кадр ошибки (Error frame)

Кадр ошибки состоит из двух различных полей.

Первое поле получается суперпозицией флагов ошибки, полученных от различных узлов.
Следующее поле - разделитель ошибки (Error Delimiter).

Для правильного завершения кадра ошибки, узел в состоянии "пассивной ошибки" может
нуждаться в доступе к шине, по крайней мере, на 3 битовых интервала (если имеет место
локальная ошибка приемника, находящегося в состоянии "пассивной ошибки").
Следовательно, шина не должна быть загружена на 100 %.

Флаг ошибки (Error flag)

Имеются два вида флага ошибки: флаг активной ошибки и флаг пассивной ошибки.
1. Флаг активной ошибки состоит из шести последовательных нулевых бит.
2. Флаг пассивной ошибки состоит из шести последовательных единичных бит, если
они не перезаписаны нулевыми битами других узлов.
Узел в состоянии "активной ошибки", обнаружив условие ошибки, сообщает об этом
передачей флага активной ошибки. Форма флага ошибки нарушает закон заполнения
бита (см. кодирование) применяемый ко всем полям от поля "начало кадра" до
разделителя CRC или разрушает фиксированную форму поля подтверждения или поля
"конец кадра". Как следствие, все другие узлы обнаруживают условие ошибки и в свою
очередь начинают передачу флага ошибки. Таким образом, последовательность
"dominant" битов, которая фактически может появиться на шине, получается
суперпозицией различных флагов ошибки, переданных отдельными узлами. Суммарная
длина этой последовательности изменяется от шести до двенадцати бит.
Узел, в состоянии "пассивной ошибки", обнаружив условие ошибки, пробует сообщить
об этом передачей флага пассивной ошибки, он ожидает появления шести
последовательных одинаковых бит, начинающих флаг пассивной ошибки. Флаг
пассивной ошибки завершен, когда после обнаружения этих 6 бит.

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

Кадр перегрузки

Кадр перегрузки содержит два битовых поля: флаг перегрузки и разделитель

перегрузки. Имеются два вида перегрузки, оба которых приводят к передаче флага
перегрузки:
1. Внутреннее состояние приемника, требует задержки следующего кадра данных или
кадра удаленного запроса данных.
2. Обнаружение "dominant" бита при передаче первого и второго битов перерыва.
3. Если узел обнаруживает "dominant" бит на восьмом бите (последнем бите)
разделителя ошибки или разделителя перегрузки, это повлечет передачу кадра
перегрузки (а не кадра ошибки). Счетчики ошибок не будут увеличены.
Передачу кадра перегрузки, обусловленного 1-м видом перегрузки, разрешено начинать в
первом битовом интервале предусмотренного перерыва, в то время как кадр перегрузки,
обусловленный 2-м и 3-м видами перегрузки, начинает передаваться на один бит позже
обнаружения "dominant" бита.
Не больше двух кадров перегрузки может быть сгенерировано, чтобы задержать
следующий кадр данных или кадр удаленного запроса данных.

Флаг перегрузки

Состоит из шести "dominant" битов. Полная форма соответствует флагу активной

ошибки.
Форма флага перегрузки нарушает фиксированную форму поля перерыва. Все другие
узлы также обнаруживают условие перегрузки и в свою очередь начинают передачу
флага перегрузки. В случае если обнаружен "dominant" бит, во время 3-го бита перерыва,
то этот бит интерпретируется как начало кадра.

Замечание:
Контроллеры, базирующиеся на CAN 1.0 и 1.1, по-другому интерпретируют 3-й бит
перерыва. Если в это время будет обнаружен "dominant" бит, то эти узлы интерпретируют
его как поле "начало кадра"; шестой "dominant" бит нарушает правило заполнения бит и
вызовет ошибку.

Разделитель перегрузки

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

Межкадровое пространство

Кадры данных и кадры удаленного запроса данных отделяются от предшествующих

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

Межкадровое пространство: содержит битовые поля: перерыв и простой шины.

Рисунок "а" приведен для узла, который был источником предыдущего сообщения.
Рисунок "в" приведен для узла в состоянии "пассивной ошибки", который был
источником предыдущего сообщения

Перерыв

Состоит из трех "recessive" бит.

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

Замечание:

Если узел имеет сообщение, которое нужно передать, и он выявляет "dominant" бит в
третьем бите перерыва, это интерпретируется, как бит "начало кадра", и, со следующего
бита, он начинает передавать сообщение, с первым битом его идентификатора, не
передавая предварительно, бита "начало кадра".

Простой шины

Период простоя шины может иметь произвольную длину. Шина свободна и любой
узел, которому нужно что-либо передать, может обращаться к шине. Сообщение, которое
ждет передачи во время передачи другого сообщения, начинает передаваться в первом
бите после перерыва. Обнаружение "dominant" бита на шине интерпретируется как
"начало кадра".

Приостановка передачи

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

Стандартный и расширенный формат кадра

Стандартный формат эквивалентен формату кадра данных / формату кадра удаленного

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

Определение передатчика / приемника

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

Приемник:
Узел называется приемником сообщения, если он не является передатчиком этого
сообщения и шина не простаивает.

4. Фильтрация сообщений

Фильтрация сообщения основана на идентификации.

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

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

5. Проверка допустимости сообщения

Момент времени, при котором сообщение является допустимым, различен для

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

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

Приемник:
Сообщение допустимо для приемников, если нет никакой ошибки до предпоследнего
бита "конец кадра". Значение последнего бита "конец кадра" рассматривается как
безразличное, "dominant" значение не ведет к ошибке формы.

6. Кодирование

Кодирование последовательности битов:

Сегменты: "начало кадра", "поле арбитража", "поле управления", "поле данных" и
"последовательность CRC" кодируются методом разрядного заполнения.
Всякий раз, когда передатчик обнаруживает в разрядном потоке, пять последовательных
одинаковых бит, он автоматически вставляет дополнительный бит в фактический
переданный разрядный поток.
Оставшиеся битовые поля кадра данных или кадра удаленного запроса данных
("разделитель CRC", "поле подтверждения", и "конец кадра") имеют фиксированную
форму. Кадр ошибки и кадр перегрузки имеют фиксированную форму также и не
кодируются методом разрядного заполнения.
Разрядный поток сообщения кодируется согласно NRZ методу (без возврата к нулю).
Это означает, что в течение всего времени передачи битов сгенерированный разрядный
уровень является или "dominant" или "recessive".

7. Обработка ошибок

Обнаружение ошибок
Существует 5 различных типов ошибки (не взаимоисключающихся):

Ошибка бита

Узел, который передает данные на шину, осуществляет контроль шины.

Ошибка бита имеет место, если значение бита на шине отличается от переданного
значения.
Исключение - посылка "recessive" бита в течение заполненного битового потока
поля арбитража или в течение поля подтверждения.
Передатчик, посылающий флаг пассивной ошибки и обнаруживший "dominant"
бит не интерпретирует это как ошибку бита.

Ошибка заполнения

Ошибка заполнения должна быть обнаружена во время передачи 6-ого бита из

последовательности 6-ти одинаковых бит в поле сообщения, которое должно быть
кодировано методом разрядного заполнения.

Ошибка CRC

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

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

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

содержит одни или более запрещенных битов. (Примечание: для приемника
"dominant" бит в течение последнего бита "конец кадра" не интерпретируется как
ошибка формы).

Ошибка подтверждения

Ошибка подтверждения обнаруживается передатчиком всякий раз, когда он не

обнаруживает "dominant" бит в "области подтверждения".

Передача сигналов ошибки

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

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

Всякий раз, когда обнаружена ошибка CRC, передача флага ошибки начинается с бита,
следующего после разделителя подтверждения, если не передается флаг ошибки для
другого условия

8. Типизация неисправностей

Неисправный узел может быть в одном из трех состояний:

активной ошибки
пассивной ошибки
отключения от шины

Узел в состоянии "активной ошибки" нормально присоединен к шине и посылает флаг

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

Для типизации неисправностей в каждом узле есть два счетчика:

1) Счетчик ошибок передачи
2) Счетчик ошибок приема

Замечание:
Значение счетчика ошибок больше чем 96 указывает на то, что шина сильно повреждена.

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

9. Генератор

Для реализации полного диапазона скоростей шины CAN, требуется кварцевый

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

Замечание:
CAN контроллеры соответствующие данной CAN спецификации и контроллеры,
соответствующие предыдущим версиям 1.0 и 1.1, используемые в одной и той же сети,
должны все иметь кварцевый генератор. Это означает, что керамические резонаторы
могут использоваться только в сети, все узлы которой соответствуют CAN
Спецификации 1.2.

10. Битовая синхронизация

Номинальная битовая скорость

Номинальная скорость передачи информации в битах - число битов в секунду

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

номинальное время передачи бита =

1/ номинальную скорость передачи информации в битах

Номинальное время передачи бита можно разделились на несколько не

перекрывающихся участков:
- Сегмент синхронизации (SYNC_SEG)
- Сегмент времени распространения (PROP_SEG)
- Сегмент TSEG1 (PHASE_SEG1)
- Сегмент TSEG2 (PHASE_SEG2)

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

Используется для синхронизации различных узлов на шине.

Предполагается, что фронт сигнала должен находиться в пределах этого сегмента.

Сегмент времени распространения

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

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

Сегменты TSEG1, TSEG2

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

Точка считывания (Sample point)

Момент времени, при котором уровень шины читается и интерпретируется, как

значение соответственного бита. Она расположена в конце TSEG1.

Время обработки информации

Время обработки информации - сегмент времени, начинающийся с точки считывания.

Шаг квантования времени

Шаг квантования времени - фиксированная единица времени, полученная из периода

генератора. Существует программируемый делитель, со значениями, от 1 до 32.
При старте с минимальным шагом квантования времени, шаг квантования времени
может иметь длину:

шаг квантования = м * минимальный шагом квантования времени

где м- значение делителя.

Длительность сегментов

SYNC_SEG - 1 шаг квантования времени.

PROP_SEG - программируется, может быть 1,2, ..., 8 квантов времени.
TSEG1 - программируется, может быть 1,2... 8 квантов времени.
TSEG2 - максимум из PHASE_SEG1 и времени обработки информации.
Время обработки информации - меньше или равно 2 квантам времени.

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

по крайней мере, от 8 до 25.

11. Аппаратная синхронизация

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

перезапускается с SYNC_SEG.

Переход пересинхронизации

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

Перехода пересинхронизации должен быть программируем от 1 до минимума из

(4, PHASE_SEG1).

Ошибка фазы границы

Ошибка фазы границы определяется положением фронта сигнала относительно

SYNC_SEG, измеряется в квантах времени. Знак ошибки фазы определен следующим
образом:

e = 0, если фронт сигнала находится в пределах SYNC_SEG.

e> 0, если фронт сигнала находится перед точкой считывания.
e < 0, если фронт сигнала находится после точки считывания предыдущего бита.

12. Пересинхронизация

Эффект от пересинхронизации - такой же как в случае аппаратной синхронизации,

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

если ошибка фазы положительна, то TSEG1 удлиняется на ширину перехода

пересинхронизации.
если ошибка фазы отрицательна, то TSEG2 укорачивается на ширину перехода
пересинхронизации.

Правила синхронизации

Аппаратная синхронизация и пересинхронизация - две формы синхронизации. Они

удовлетворяют следующим правилам:
1. Допускается только одна синхронизация в пределах битового интервала.
2. Фронт сигнала будет использоваться для синхронизации только, если значение,
обнаруженное при предыдущей точке считывания (предыдущее значение на шине)
отличается из значения на шине сразу после фронта.
3. Аппаратная синхронизация происходит всякий раз, когда есть переход от "recessive"
бита к "dominant" в течение простоя шины.

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 системной
конфигурации.

Поддерживаются следующие функции канала обмена 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
Multicast
Communication Process Data Object I/O-Message
Channel APDU
Object
Maximal
27 I/O- Transmit Messages
Number of 32 Embedded
512 Transmit PDOs 512 1701 I/O Receive Messages
Communication Objects per
Receive PDOs per device 32 Multicast
Objects per device
Channels for each of up to
Device
6 bytes
Maximal length 8 bytes fragmented: Arbitrary
8 bytes fragmented: 64 *
of Data Field length
4 bytes
Unfragmented: No overhead,
three "Transport Classes"
Unfragmented: No supported:
Unfragmented: 2
overhead, Notify/Read
byte protocol
Protocol "Stored-Event"-protocol Unacknowledged,
overhead,
(CAL/CMS) Acknowledged by
Unacknowledged
Unacknowledged Server Connection
Object,
Acknowledged by
 Application

Fragmented:
Acknowledged
fragmented
Fragmented: protocol with
Unacknowledged fragmented Acknowledge
protocol 1 byte protocol after reception of
overhead per frame complete block 4
bytes protocol
overhead per
fragment
On Request of
Message local or remote Cyclic
Production application Change-of-State Specified by
Triggering Cyclic/acyclic Application specific object model
Modes synchron

Maximum number of
mappable application
objects/PDO dependent
on data size of objects (1-
bit objects: 64 application
Mapping of
objects mappable)
Application
Definition of Application
Objects
objects by means of
"Mapping Parameter
Record" (configurable)
Dynamic mapping
supported
Arbitrary number of
Network Data
Application objects mappable
Descriptor
with fragmented protocol.
defines size,
Definition of Application
granularity and
objects by means of
data type of I/O
Assembly Object (several
data of
Assembly Objects possible)
Embedded
Dynamic mapping supported
Вызов (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
27 Explicit Transmit 4 channels per Embedded
Maximum
128 Client SDOs, 128 Messages 1701 Explicit Object. 32 Embedded
number of
Server SDOs per device Receive messages per Objects per Logical
channels
device Device
< 5 byte:
Acknowledged
< 6 bytes Acknowledged
unfragmented 4 byte: < 7 byte: Acknowledged
unfragmented 5 byte
Fragmented unfragmented 6 byte:
Fragmented transmission
transmission (7 bytes Fragmented transmission.
Protocol (3 bytes per fragment)
per fragment) Each (6 bytes per fragment)
Acknowledgement of
frame acknowledged Each frame acknowledged
complete data block. Max.
Any length (CAL Any length
255 byte
Multiplexed Domain
protocol)
Dynamic
establishment by
means of
Unconnected Dynamic
Dynamic
Message establishing by
establishment by
Manager means of
Establishing means of SDO
Group 2 Only Connection
of Manager
devices: Manager
Connections Default predefined
Allocation of Master/Slave Set of
connections
Explicit Connections Set
Message from
Predefined
Connection Set

Initiate, Abort Open/Close Creation,

Open/Close Read, Write,
Upload/Download Configuration, Start, Stop,
Connection Event, Action
Segment/Domain Reset etc. of Objects
Services and
Arguments Index and Subindex of Object Directory Entry Channel Number,
Object attribute access Attribute/Action/Event
addressed
path, Service arguments Identifier

Установление связей для обмена данных процесса

Распределение идентификаторов для передаваемых сообщений и , соответственно,

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

В системе с предопределенным множеством сообщений "функции" и идентификаторы

сообщений уже определены. DeviceNet также использует предопределенное множество
сообщений для системы со структурой 1:n. Master устройство, предварительно разместив
у себя множество связей со Slave устройствами, "знает" ID сообщений для передачи
запроса и ID сообщений для получения ответа, который включает Slave MAC-ID в
соответствии с предопределенным множеством связей. Также возможно не
предопределять идентификаторы сообщений.

Сетевое управление

Так как в CAN-сети мы имеем дело с распределенными приложениями, должны

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

В DeviceNet каждое соединение контролируется. Поэтому каждая ожидающая

сообщение конечная точка имеет "Inactivity/Watchdog" таймер, чтобы контролировать
прибытие сообщения согласно предопределенному времени ожидания. Если время
истекает, соединение выполняет действие "Timeout". На рис. 7 показана диаграмма
изменения состояний у объекта I/O.

Рис. 7. Device Net I/O Connection Object State Transition Diagram

После получения вызова CREAT ( Explicit сообщение) соединение настраивается при

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

Контроль может осуществляться также посредством Heartbeat сообщения, которое

может посылаться устройствам посредством UCMM в форме сообщения. В поле данных
этого сообщения передается состояние устройства. Heartbeat сообщение вызывается
объектом Idendity.

Профайлы устройств

Для открытых автоматических систем помимо обеспечения связи от входящих в их

состав устройств требуется также обеспечение возможности взаимодействия и
взаимозаменяемости. Поэтому протоколы высокого уровня (такие как DeviceNet)
описывают функциональные возможности устройств в виде модели устройства ("Device
Model").

Помимо описания функциональности устройств модель устройства должна также

содержать ряд важных параметров (статус, диагностическую информацию,
коммуникационные возможности, конфигурационные параметры и т.д.). На рис. 8
показана модель устройства DeviceNet.

Рис. 8. DeviceNet Object Model

DeviceNet профайл должен содержать следующую информацию:

модель объекта для устройства

формат данных I/O для устройства
конфигурационные данные и внешние интерфейсы для этих данных

В таблице 3 показаны главные функции объектов в DeviceNet.

Таблица 3. Objects of a DeviceNet node

Object Function
Connection Instantiates connections (I/O or Explicit Messaging)
DeviceNet Maintains configuration and status of physical attachments to DeviceNet.
Message
Routes received Explicit Messages to appropriate target objects
Router
Groups attributes of multiple objects into a single block of data, which can be
Assembly
sent and received over a single connection
Parameter Provides a standard means for device configuration and attribute access
Identity Provides general information about the identity of a device
Application Supplies application-specific behaviour and data
 Заключение

Протокол CAN применяется в real-time системах для решения различных задач. В

настоящий момент развиваются несколько видов CAN протоколов высокого уровня,
таких как CAL ,OSEK/VDX, SAE J1939, CANopen, DeviceNet, SDS ,CAN-Kingdom , в
основе которых лежит канальный протокол CAN2.0 (Bosch) , и на основе этих
протоколов можно решать проблемы, возникающие в real-time системах, которые
невозможно разрешить при помощи других известных протоколов, скажем, TCP/IP.