Иванов Ю.И., Югай В.Я. Интерфейсы средств автоматизации

Подождите немного. Документ загружается.

151

Рис. 4.2. CAN кадр

Управляющее поле содержит бит расширения идентификатора (IDE –

identifier extension), который указывает тип формата кадра: стандартный (0)

или расширенный (1). В этом поле также находятся четыре бита DLC для

указания длины поля данных и зарезервированный для будущего применения

бит R0. В расширенном формате после бита IDE следуют 18 дополнитель-

ных бит идентификатора (удлинение поля Arbitration Field до 32 бит). За

управляющим полем идут поле данных (0-8 байт) и поле циклического кон-

троля CRC длиной 15 бит плюс рецессивный бит ограничителя этого поля.

Образующий полином CRC для контроля кадра – (x

+ x

+ 1).

Поле подтверждения (АСК) состоит из области АСК длиной в 1 бит и ог-

раничителя поля АСК. АСК-бит помещается на шину передатчиком как ре-

цессивный (логическая 1). Приемники, корректно принявшие эти данные,

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

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

вильно принял его сообщение. Сообщения подтверждаются приемниками не-

зависимо от результата тестирования данных при приёме.

Конец сообщения указывается EOF (7 рецессивных бит), после которого

идет пауза. Длина паузы равна минимальному количеству битов (3 бита), от-

деляющих последовательные сообщения.

В CAN протоколе не используется подтверждение сообщений. Вместо

этого сигнализируется о возникших ошибках передачи. Всего

в CAN-

протоколе реализовано пять механизмов проверки на наличие ошибок. Флаг

ошибки – это сообщение, содержащее 6 доминантных бит подряд. Другие уз-

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

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

• Циклический контроль. Контролируемые поля кадра от SOF до CRC.

При использовании этого метода в конце

передачи добавляются

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

происходит его повторное вычисление и сравнение с получен-

ным кодом циклического контроля. Если эти два значения не

совпадают, то выявляется ошибка CRC.

152

• Контроль кадра. Проверяется соответствие структуры передаваемого

кадра его фиксированному формату и размеру. Ошибки, кото-

рые могут возникнуть при проверке кадра, получили название

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

• Ошибки подтверждения. Как уже ранее было сказано, принятые кадры

подтверждаются всеми приемниками. Если передатчик не полу-

чил никакого подтверждения, то это может

означать, что при-

емники обнаружили ошибку (искажено поле АСК), либо прием-

ники вообще отсутствуют в сети.

Следующие два алгоритма определения ошибок реализованы в протоколе

CAN на битовом уровне:

• Мониторинг шины. Одна из особенностей CAN сети состоит в том, что

передающий узел контролирует сигнал на шине во время пере-

дачи. Таким

образом, каждый узел может наблюдать за уровнем

сигнала на шине и определять различие переданного и принято-

го бита. Расхождение сигналов в поле арбитража требует пре-

кращения передачи, а расхождение в других полях кадра гене-

рирует ошибку.

• Заполнение битами. В CAN используется сигнальный код NRZ. При

длинных последовательностях битов с одним

и тем же значени-

ем возможен сбой синхронизации. Если в сообщении подряд

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

матически вставляет дополнительный бит. Этот бит автоматиче-

ски удаляется из сообщения приемниками. Если будет получено

шесть и более последовательных битов с одним и тем же значе-

нием, это считается

ошибкой.

Если в течение передачи кадра хотя бы один узел обнаружит ошибку (ло-

кальная ошибка), то он передает кадр ошибки, который аварийно завершает

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

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

сети, не обнаружившие ошибку, после приема кадра

ошибки должны повто-

рить передачу кадра ошибки (глобализация ошибки), поэтому максимальная

длина этого поля может достигать 12 доминантных бит. Завершается кадр

ошибки ограничителем флага ошибки из 8 рецессивных бит. После стандарт-

ной паузы (3 бита), прерванная кадром ошибки передача должна быть повто-

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

ни, соответствующего

передаче 23 битов, отсчитываемого с момента обна-

ружения ошибки.

Для реализации процедур самоконтроля каждый узел CAN сети содержит

два счетчика: счетчик ошибок приема (REC) и счетчик ошибок передачи

(TEC). Счетчики автоматически инкрементируются после обнаружения каж-

153

дой ошибки и декрементируются после корректной передачи или приема

кадра. В зависимости от состояния счетчиков ошибок узел может находиться

в одном из трех состояний: активной ошибки, пассивной ошибки, отключен

от шины.

Состояние активной ошибки является основным для узла CAN сети и

предполагает его нормальное функционирование. При обнаружении ошибки

в этом состоянии

узел посылает кадр активной ошибки (6 доминантных бит).

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

ошибок в любом из счетчиков не превышает 127. Если число ошибок превы-

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

ошибок. При числе ошибок более 127, но менее 256 узел переходит в состоя-

ние пассивной ошибки.

Состояние пассивной ошибки свидетельствует о часто повторяющихся

ошибках. Узел из этого состояния может самостоятельно вернуться к актив-

ной ошибке, если число ошибок в счетчиках станет менее 128. При обнару-

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

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

любого другого узла.

При повторении прерванной передачи этого узла долж-

на быть сделана дополнительная пауза (8 рецессивных бит) для того, чтобы

не мешать передаче кадров других узлов.

Если число ошибок в любом из счетчиков превысит 255, узел должен от-

ключиться от шины (на практике REC содержит только 8 двоичных разрядов

и поэтому число ошибок приема не может

превысить этот порог). Самостоя-

тельно CAN контроллер узла не может вернуться в рабочее состояние. Если

произведен внешний сброс, CAN контроллер возвращается в состояние ак-

тивной ошибки и после паузы 128х11 (1408) может передавать сообщения.

CAN протокол определяет правила накопления числа ошибок в счетчиках

REC и TEC. В зависимости от вида ошибки увеличение числа ошибок в счет

чиках может быть от 1 до 8 при обнаружении однократной ошибки. Декре-

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

всегда только на 1. Это позволяет присваивать разные веса различным ошиб-

кам.

Например, обнаружение ошибки при приеме увеличивает REC на единицу

одновременно с отправкой кадра активной ошибки; если принимается доми-

нантный бит после отправки

узлом кадра активной ошибки, REC увеличива-

ется на 8, т.к. это означает, что только данный узел обнаружил ошибку. TEC

увеличивается на 8 при передаче кадра ошибки. Успешная передача кадра

уменьшает TEC на 1 (если значение не 0). Успешный прием кадра узлом

уменьшает REC (если он был не 0) на 1 в состоянии активной ошибки; если

узел был в состоянии

пассивной ошибки, в REC устанавливается величина от

154

119 до 127 (т.е. при TEC менее 128 узел перейдет в состояние активной

ошибки).

Любой узел может также послать кадр перегрузки (overload frame), если,

во-первых, он не успевает обрабатывать поступающие сообщения и не может

обеспечить прием следующего сообщения, во-вторых, при приеме доминант-

ных бит в паузе между кадрами (это может означать потерю синхронизации

при приеме). Кадр перегрузки имеет такой же формат, как и кадр ошибки, но

передается всегда только после завершения приема кадра. А кадр ошибки

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

увеличивает состояние счетчиков ошибок и не приводит к повторной переда-

че кадров. Допускается передача узлом не

более 2 кадров перегрузки подряд.

В соответствии со всеми процедурами контроля:

• передача кадра считается успешной, если не обнаружено ошибок до кон-

ца поля EOF;

• прием кадра считается успешным, если не обнаружено ошибок и в тече-

ние межкадрового интервала (3 бита после EOF).

Необходимо помнить, что CAN протокол не содержит эффективных

средств контроля

и восстановления искаженных данных кроме процедуры

контроля CRC. Процедуры LLC не предусмотрены, несмотря на высокую

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

полнительные средства контроля данных, они должны реализовываться HLP

протоколами.

В настоящее время выпускают CAN контроллеры, которые поддерживают

одну из трех версий протокола. Версия CAN 2.0A поддерживает работу толь-

ко с кадрами стандартного формата

, имеющими 11-битный идентификатор.

CAN 2.0B passive обеспечивает передачу кадров стандартного формата, а

прием и обработку кадров и стандартного формата, и расширенного формата

с 29-битным идентификатором. CAN 2.0B active обеспечивает обработку

кадров обоих форматов.

Стандартная структура CAN контроллера приведена на рис. 4.3. Очевид-

но, что CAN контроллер должен содержать буферные ЗУ и для передаваемых

данных, и для принимаемых данных.

Реализация процедур CAN протокола,

как правило, производится аппаратно с передачей через трансивер выходных

сигналов узла (Tx) и входных сигналов с шины (Rx). Приемный фильтр аппа-

ратно производит селективную запись принимаемых кадров по их идентифи-

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

чивать хранение, по крайней мере, одного сообщения, а буфер приема

– не

менее двух сообщений. Чаще всего CAN контроллеры имеют больший объем

буферных ЗУ. Доступ к данным в буферных

155

Рис. 4.3. Структура CAN контроллера

ЗУ может производиться по алгоритму FIFO либо в более сложных реализа-

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

фейс CAN контроллера с управляющим микроконтроллером узла – стандарт-

ный. Через этот интерфейс производится настройка параметров, режимов,

приемного фильтра и т.п., а также обмен данными с CAN шиной. В настоя-

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

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

CAN сети.

В связи с тем, что CAN протокол определяет только процедуры физиче-

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

связанных, например, с процедурами LLC, процедурами выбора параметров

и режимов при инициализации

работы узлов, разработаны так называемые

CAN HLP протоколы.

4.1.3. CAN HLP протоколы

К настоящему времени известно уже более четырех десятков CAN HLP.

Среди CAN HLP наибольшее распространение в системах промышленной ав-

томатизации получили четыре, поддерживаемых ассоциацией CiA:

CAL/CANopen, CAN Kingdom, DeviceNet и SDS.

CAL/CANopen. CAL не является ориентированным на конкретные при-

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

кретным устройствам, и

не определяет содержание передаваемых данных, но

предлагает стандартизованные элементы сетевого сервиса прикладного уров-

ня. CAL включает в себя четыре составные части:

• спецификация CAN сообщений (CMS CAN Message Specification);

Реализация

протокола

Фильтр

приема

кадров

Буфер

передачи

данных

Буфер

приема

данных

(формирование кадров,

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

подтверждение,

синхронизация,

бит-стаффинг)

Интерфейс

контроллера

156

• сетевое управление (NMT Network Management);

• распределение идентификаторов (DBT Identifier Distributor);

• управление уровнем (LMT Layer Management).

CMS определяет типы объектов взаимодействия в рамках объектно-

ориентированного подхода, правила и механизмы передачи данных разных

типов посредством CAN кадров, включая передачу пакетов длиной более 8

байт. Сетевое управление построено на взаимодействии типа ведущий-

ведомый (master-slave). Один модуль сети является NMT-мастером, все ос-

тальные

– NMT-ведомые. NMT-мастер инициализирует и управляет NMT-

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

общаться между собой посредством CMS-сервисов. Также в задачи сетевого

управления входят контроль ошибок и конфигурирования устройств. Благо-

даря DBT-сервисам происходит бесконфликтное распределение идентифика-

торов среди модулей под контролем DBT-мастера. Посредством LMT-

сервисов возможны запрос и изменение текущих

параметров в модулях (зна-

чений идентификаторов, скорости передачи, битового квантования и т. п.)

непосредственно из CAN-сети.

Результатом дополнения CAL явилось появление более "конкретного"

протокола CANopen. По существу CANopen является приложением приклад-

ного уровня CAL. В сети CANopen на прикладном уровне модули обменива-

ются между собой объектами-сообщениями COB (Communication Object),

включающими в себя один или несколько кадров. Администрированием

сети

занимается NMT-мастер, который инициализирует устройства, обеспечивает

контроль ошибок, а также производит их периодическую "перекличку" (Life

Guarding) для выявления узлов, находящихся в нерабочем состоянии ввиду

физического отсутствия или отключения от шины (bus off) по счетчику оши-

бок. Для максимального упрощения процесса интеграции модулей в единую

сеть используется концепция профилей. К настоящему времени завершено

формирование

следующих профилей устройств:

• модули ввода/вывода (аналоговые и цифровые) (DSP-401);

• приводы и модули управления перемещением (DSP-402);

• элементы человеко-машинного интерфейса (DSP-403);

• измерительные устройства и регуляторы (WD-404);

• кодеры (DSP-406).

CAN Kingdom. Протокол шведской компании KVASER-AB занима-

ет особое место среди CAN HLP не только из-за своего необычного названия

(CAN королевство), но и в

значительной степени благодаря оригинальной

концепции сетевого взаимодействия и эффективности CAN-приложений на

его основе. Основой сетевого взаимодействия CAN Kingdom является прин-

цип: "Модули обслуживают сеть" (MSN Modules Serves the Network) в отли-

157

чие от принципа "Сеть обслуживает пользователей" (NSM Network Serves the

Modules), свойственного компьютерным сетям.

CAN система на базе протокола CAN Kingdom обладает следующими

особенностями:

• Распределение CAN идентификаторов находится под полным контро-

лем разработчика.

• Максимальное время прохождения любого сообщения в сети предска-

зуемо.

• Во время начальной инициализации системы происходит обязатель-

ный этап настройки протокола, включая построение

форматов данных,

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

идентификаторов и т. д.

• В системе всегда должен присутствовать (как минимум до завершения

настройки протокола) супервизор (Король), производящий инициали-

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

не может принимать участие в сетевом обмене без разрешения Короля

• Перед инициализацией сети каждый модуль должен иметь свой номер

(CAN Kingdom не описывает конкретный способ установки номера

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

или конфигурация соединителя) и "знать" идентификатор сообщения

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

сети.

• В сеть CAN Kingdom возможна интеграция любых CAN-модулей,

включая разработанных для других

протоколов, например, DeviceNet

или SDS.

• Не существует каких-либо рекомендуемых скоростей передачи дан-

ных. Но за первые 200 мс после подачи питания узел обязан настро-

иться на прослушивание шины на скорости 125 кбит/с. Допустимы от-

личающиеся от ISO 11898 спецификации физического уровня.

Наличие одного центра-Короля, который содержит всю информацию о

системе, избавляет от

использования профилей устройств, часто применяе-

мых в других HLP.

DeviceNet – протокол, разработанный и опубликованный в 1994 году

компанией Allen-Bradley корпорации Rockwell, – недорогое, простое и эф-

фективное решение для объединения разнообразных устройств промышлен-

ной автоматизации. Важной особенностью сети DeviceNet является возмож-

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

ется применение нескольких источников питания в

любой точке шины. Все

это дает возможность построения автономной сети, не зависящей от наличия

или качества внешнего питания.

Сообщения в сети DeviceNet могут быть двух типов:

158

• Сообщения ввода/вывода (I/O messages) предназначены для целей

управления устройствами и передачи данных в реальном времени ме-

жду узлами в широковещательном или в режиме точка-точка. Исполь-

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

содержание сообщения.

• Явные сообщения (Explicit messages) для многоцелевого обмена дан-

ными в режиме точка- точка. Обеспечивают типичный сервис

за-

прос/ответ. Используют идентификаторы с низким приоритетом и

применяются обычно для конфигурирования устройств и целей диаг-

ностики.

При необходимости передачи данных длиной более 8 байт применяется

механизм фрагментации. В зависимости от потребностей обмена и возмож-

ностей модулей, возможны мастер-слуга (master-slave), мультимастерный

(multi-master), или равноправный (peer to peer) способы взаимодействия уст-

ройств. Пересылки данных

могут инициироваться путем опроса, циклически

или по изменению их значения (change of state). Максимальное число узлов в

сети DeviceNet – 64.

SDS – разработка компании Honeywell Inc. Наряду со стандартом

DeviceNet, SDS представляет собой еще одно недорогое и законченное реше-

ние для сетевого управления интеллектуальными устройствами в системах

промышленной автоматизации. Сообщения в сети SDS носят название APDU

(Application layer Protocol Data Unit) – блоки данных протокола прикладного

уровня. APDU представляет

собой кадр стандартного формата (расширенный

формат в SDS-сети не применяется). Сеть SDS всегда требует наличия един-

ственного мастера-менеджера сети как минимум на этапе включения для вы-

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

чие нескольких мастеров на шине, но они должны функционировать в преде-

лах своих адресных доменов,

а при включении сети только один из них мо-

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

устройств.

APDU используется в следующих сервисах прикладного уровня:

• change of State (OFF, ON, OFF ACK, ON ACK) – обнаружение измене-

ния состояния логического устройства;

• write (ON State, OFF State, ON State ACK, OFF State ACK) – управле-

ние состояниями логического устройства.

• channel – обеспечение как широковещательного (multicast), так и рав-

ноправного (peer to peer) каналов

соединения;

• connection – открытие/закрытие индивидуальных типов соединения;

• write – чтение атрибутов объектов устройства;

• read – изменение атрибутов объектов устройства;

• action – команда объекту устройства выполнить действие;

159

• event – сигнализация о событии объектом устройства.

При инициализации взаимодействия модулей сети SDS используются 4 сер-

висных функции-примитива:

• запрос (Request) – генерация APDU устройством-инициатором соеди-

нения;

• ответ (Response) – ответный APDU устройства-ответчика;

• индикация (Indication) – фиксация факта приема APDU устройством-

ответчиком;

• подтверждение (Confirm) – подтверждение приема APDU устройст-

вом-инициатором.

Применение CAN протокола в качестве коммуникационного средства в

системах автоматизации в настоящее время постоянно расширяется. Универ-

сальность и функциональная гибкость позволяет создавать эффективные ин-

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

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

HLP протоколов. Следует учитывать, что достоинства CAN протокола реали-

зуются существенным усложнением алгоритмов работы интерфейсных

средств. Этот фактор не является

препятствием для применения этой комму-

никационной технологии. Существует весьма широкая номенклатура техни-

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

сложных функциональных модулей, содержащих встроенные CAN интер-

фейсы.

4.1.4. Средства реализации CAN технологии

Многие ведущие производители электронных компонентов выпускают

CAN – контроллеры и трансиверы в виде интегральных схем.

CAN-трансиверы, реализующие физический уровень коммуникационной

сети, производятся компаниями Philips, Bosch и др. (табл. 4.2).

CAN-трансивер фирмы Atmel – интегральная схема ATA6660 (рис. 4.4),

выполненная по технологии Atmel Smart Power BCD60-III. Она специально

разработана для высокоскоростного CAN-контроллера (CAN-C) с дифферен-

циальным режимом передачи данных между CAN-контроллерами и физиче-

скими дифференциальными линиями шины.

160

Таблица 4.2

Производитель

Bosch

Mietec

Philips

Semiconductors

SGS-Thomson

Temic (Siliconix)

Texas Instruments

Тип

CF150B

MTC-3054

82C250

82C251

L9615

Si9200EY

SN65HVD230

(SN65HVD231)

SN65HVD232

Макс. ско-

рость

[MБод]

0.5 1 1 1 0.5 1 1 1

Температ.

защита

(1,2) n.a. yes yes (1, 2) yes yes yes

Задержка

[нс]

230 100 170 170 230

120

(4)

70 70

Напряжение

питания [В]

5 5 5 5 5 5 3,3 3,3

Ток потреб-

ления [мA]

<80 110 <70 <80 <80 70 10 10

Ток в пас-

сивном ре-

жиме [мкA]

n.a. 300 <170 <275 n.a. n.a.

370

(10)

n.a.