The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа

previous up down next index index
Previous: 4.1.3 IEEE 802.4 (Маркерная шина)    UP: 4.1.1 Ethernet (IEEE 802.3)
Down: 4.2 Наложенные сети
    Next: 4.1.5 Локальные сети ArcNet

4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)
Семенов Ю.А. (ГНЦ ИТЭФ)

Стандарт CAN (Controller Area Network - http://www.kvaser.se/can/protocol/index.htm или http://www.omegas.co.uk/can/canworks.htm, а также www.can-cia.de) был разработан в Германии компанией Robert Bosch gmbh для автомобильной промышленности (1970 годы). Сеть CAN ориентирована на последовательные каналы связи, выполненные из скрученных пар проводов (или оптических волокон), стандарт определяет протоколы физического уровня и субуровеней MAC и LLC. Все узлы сети равноправны и подключаются к общему каналу. Уровни сигналов протоколом не нормированы. В CAN использована кодировка типа NRZ (Non Return to Xero). Для распознавания сигнатур начала (SOF) и конца (EOF) кадра используется бит-стафинг. В настоящее время в ЕС разрабатывается новый протокол для сети автомобиля, который бы позволял передачу высококачественного стерео аудио и видео сигналов, обеспечивал работу с мобильными телефонными сетями и Интернет. Предполагается, что пропускная способность протокола составит 45 Мбит/c

Высокая надежность и дешевизна сделала сети CAN привлекательными для промышленности и науки. Сеть предназначена для сбора информации и управления в реальном масштабе времени, но может быть использована и для других целей. Канал can реализует принцип множественного доступа с детектированием столкновений (CSMA/CD - Carrier Sense Multiple Access with Collision Detection, аналогично Ethernet). Сеть может содержать только один сегмент. В соответствии со стандартом ISO 11898 сеть способна работать при обрыве одного из проводов, при закоротке одного из проводов на шину питания или на землю. Скорость работы канала программируется и может достигать 1 Мбит/с. Недиструктивная схема арбитража позволяет сделать доступ к общему каналу существенно более эффективным, чем в случае Ethernet. В настоящее время действуют две версии стандарта с полями арбитража длиной в 11 бит (2.0a) и 29 бит (расширенная версия, 2.0b). Код арбитража одновременно является идентификатором кадра и задается на фазе инициализации сети. При одновременной попытке передачи кадров двумя узлами арбитраж выполняется побитно с использованием схемы проволочного "И", при этом доминантным состоянием является логический "0". Выигравший соревнование узел продолжает передачу, а проигравший ждет момента, когда канал освободится. Код-адрес объекта (узла CAN) задается с помощью переключателей на плате CAN при формировании сети.

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

Рис. 4.1.4.1 Стандартный информационный кадр 1 2.0a CAN

Кадр начинается с доминантного бита начала кадра (логический нуль, SOF - start of frame). Далее следует поле арбитража (идентификатор кадра), содержащее 11 бит (эти разряды носят имена id-28, ..., id-18) и завершающееся битом RTR (remote transmission request) удаленного запроса передачи. В информационном кадре RTR=0, для кадра запроса RTR=1. Семь наиболее значимых бит id-28 - id-22 не должны быть никогда все одновременно равными 1. Первым передается бит id28. Доминантные биты r0 и r1 (=0) зарезервированы для будущего использования (в некоторых спецификациях бит r1 называется IDE и относится для стандартных кадров к полю управления). Поле DLC (Data Length Code; биты поля имеют имена dcl3 - dcl0) несет в себе код длины поля данных в байтах. Поле данных, размещенное вслед за ним, может иметь переменную длину или вообще отсутствовать. CRC - циклическая контрольная сумма. В качестве образующего полинома при вычислении CRC используется x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1. Формально, следующий за контрольной суммой бит-разграничитель (=1) принадлежит полю CRC. Поле отклика (ack) содержит два бита, первый из которых первоначально имеет уровень 1, а узлы получатели меняют его значение на доминантное (логический 0). Бит используется для сообщения о корректности контрольной суммы. Второй бит поля всегда имеет уровень логической 1. Завершающее поле EOF (end of frame) содержит семь единичных бит. За этим полем следует поле-заполнитель (INT) из трех единичных бит, после него может следовать очередной кадр. Формат расширенного информационного кадра сети can показан на рис. 4.1.4.2.

Рис. 4.1.4.2. Расширенный информационный кадр 2.0b CAN

Однобитовое субполе SRR (substitute remote request) включено в поле арбитража (идентификатора кадра) и всегда содержит код 1, что гарантирует преимущество стандартного информационного кадра (2.0a) случае его соревнования с расширенным кадром (2.0b) (при равных 11 битах идентификатора). Субполе IDE (identifier extension) служит для идентификации расширенного формата и для этого типа кадра всегда имеет уровень логической 1. Вслед за IDE следует 18-битовое поле (биты имеют имена id-17, ..., id-0; первым передается бит id-28) расширения идентификатора кадра. Контроллеры 2.0b полностью совместимы с кадрами 2.0a и могут посылать и принимать пакеты обоих типов. Идентификаторы в пределах одной сети должны быть уникальными. Следует иметь в виду, что 18-битное поле расширения идентификатора можно при определенных условиях использовать и для передачи информации. Идентификатор не является адресом места назначения, а определяет назначение передаваемых данных (адресация по содержанию). По этой причине пакет может быть принят отдельным узлом, группой узлов, всеми узлами сети или не воспринят вообще. Предельное число различных идентификаторов для версии 2.0a составляет 2032, а для 2.0b превышает 500 миллионов.

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

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

Протокол can имеет развитую систему диагностики ошибок. В результате вероятность не выявленной ошибки составляет менее 4.7 10-11. При выявлении ошибки кадр отбрасывается и его передача повторяется.

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

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

  • Информационный.
  • Удаленный запрос (требование присылки информационного кадра с тем же идентификатором, что и запрос).
  • Сообщение об ошибке.
  • Уведомление о перегрузке канала (требует дополнительной задержки до и после передач информационных кадров и удаленных запросов).

Информационные кадры и удаленные запросы могут использовать как стандартные, так и расширенные форматы кадров (2.0a и 2.0b).

Кадр удаленного запроса может иметь стандартный и расширенный форматы. В обоих случаях он содержит 6 полей: SOF, поле арбитража, поле управления, CRC, поля ACK и EOF. Для этого типа кадров бит RTR=1, а поле данных отсутствует вне зависимости от того, какой код содержится в субполе длины.

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

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

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

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

Поля SOF, идентификатор, управляющее поле, данные и CRC кодируются таким образом, что при появлении пяти идентичных бит подряд, в поток вставляется бит противоположного уровня. Так 0000000 преобразуется в 00000100, а 1111110 в 11111010. Это правило не распространяется на CRC-разделители, поля ACK и EOF, а также на кадры сообщения об ошибке или переполнении. Существует 5 разновидностей ошибок (таблица 3.3.4.1).

Таблица 4.1.4.1 Разновидности ошибок.

Тип ошибки

Описание

bit error

Передающий узел обнаружил, что состояние шины не соответствует тому, что он туда передает

stuff error

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

CRC error

Приемник обнаружил ошибку в контрольной сумме.

form error

Обнаружено нарушение формата кадра

acknowledgment error

Выявлен неверный уровень первого бита поля ack.

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

Номинальное время, выделенное для передачи одного бита, включает в себя четыре временные области: sync_seg, prop_seg, phase_seg1, phase_seg2 (рис.3.4.4.3).

Рис. 4.1.4.3 Временные зоны периода передачи одного бита

Первая временная область (SYNC_SEG) служит для синхронизации работы различных узлов сети. Область PROP_SEG предназначена для компенсации временных задержек в сети и равна сумме времени распространения сигнала по каналу и задержки во входных компараторах. PHASE_SEG1 и PHASE_SEG2 служат для компенсации фазовых ошибок и могут увеличиваться или уменьшаться после синхронизации. T0 - минимальный квант времени, используемый для формирования временной шкалы в пределах периода передачи одного бита (длительность внутреннего такта может быть значительно короче). Момент стробирования определяет момент времени, когда проверяется состояние канала. Этот момент должен быть синхронным для всех узлов сети. Длительность этих временных областей может задаваться программно. Чем длиннее канал, тем меньшую скорость передачи информации он может обеспечить (см. табл. 3.3.4.2).

Таблица 4.1.4.2 Зависимость пропускной способности канала от его длины

Длина канала в метрах

Пропускная способность сети в Кбит/с

100

500

200

250

500

125

6000

10

В сетях CAN используются 9-, 6- и 5-контактные разъемы. Тип разъема, или какие либо его характеристики стандартом не регламентируются. Разъем определяется протоколом HLP (High Layer Protocol).

Previous: 4.1.3 IEEE 802.4 (Маркерная шина)    UP: 4.1.1 Ethernet (IEEE 802.3)
Down: 4.2 Наложенные сети    Next: 4.1.5 Локальные сети ArcNet




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру