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 бита, передается внутри поля управления.

    Поле данных (стандартный и расширенный форматы)
(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).

    Флаг ошибки (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)

Вызов (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

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

    Распределение идентификаторов для передаваемых сообщений и , соответственно, получаемых сообщений устанавливает коммуникационные пути в 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

Заключение

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