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

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

• Data Frame;

• Remote Frame;

• Error Frame;

• Overload Frame.

Data Frame – наиболее часто используемый тип сообщения (рисунок 3.30). Он состоит из следующих основных частей :

· поле арбитража (arbitration field) определяет приоритет сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть;

· поле данных (data field) содержит от 0 до 8 байт данных;

· слот подтверждения (Acknowledgement Slot) (1 бит),.

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

Remote Frame – это Data Frame без поля данных и с выставленным битом RTR (1 – рецессивный бит).

Основное предназначение Remote кадра – запрос передачи данных. Такая схема позволяет уменьшить суммарный трафик сети.

Error Frame – это сообщение, явно нарушающее формат сообщения CAN. Передача такого сообщения приводит к тому, что все узлы сети регистрируют ошибку формата CAN-кадра, и в свою очередь автоматически передают в сеть Error Frame.

Рисунок 3.30 − Data frame стандарта CAN 2.0A.

Результатом этого процесса является автоматическая повторная передача данных в сеть передающим узлом.

Error Frame имеет всего два поля:

· Error Flag – 6 бит одинакового значения (и таким образом Error frame нарушает проверку Bit Stuffing);

· Error Delimiter – 8 рецессивных битов. Error Delimiter вынуждает другие узлы сети обнаружившие Error Frame послать в сеть свой Error Flag.

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

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

Среди подобного многообразия наибольшее распространение, в особенности в системах промышленной автоматизации, получили четыре, поддерживаемых ассоциацией CiA и рассмотренных ниже. Это CAL/CANopen, CAN Kingdom, DeviceNet и SDS (Smart Distributed System).

CAL /CANopen

Фундаментом CAL служит канальный уровень CAN.

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

CAL предлагает стандартизованные элементы сетевого сервиса прикладного уровня и включает в себя четыре составные части:

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

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

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

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

CMS определяет типы объектов, правила и механизмы передачи данных разных типов посредством CAN фреймов.

Сетевое управление взаимодействием типа мастер – слуга. Один модуль сети является NMT-мастером, все остальные NMT-ведомые.

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

CANopen поддерживает синхронный и асинхронный, циклический и ациклический (событийный) режимы передачи данных.

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

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

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

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

CANopen содержит собственные правила битового квантования, а также определяет три рекомендуемых типа соединителей:

1. 9-контактный D-Sub (DIN 41652);

2. 5-контактный круглый Mini (ANSI/B93.55M-1981);

3. 5-контактное открытое клеммное соединение.

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

В сети CANopen определены восемь градаций скоростей передачи данных: 1 Мбит/с, 800 кбит/с, 500, 250, 125, 50, 20 и 10 кбит/с.

Поддержка скорости 20 кбит/с является обязательной для всех модулей.
В сети CANopen на прикладном уровне модули обмениваются между собой объектами – сообщениями COB (Communication Object), включающими в себя один или более CAN фреймов. Всего существует четыре типа таких объектов:

· данных процесса Process Data Objects (PDO);

· сервисных данных Service Data Object (SDO);

· специальных функций Special Function Objects;

· сетевого управления Network Management Objects.

SDO-объекты позволяют модулям обмениваться данными любого объема (при последовательностях более 8 байт благодаря использованию нескольких CAN фреймов) в ацикличном низкоприоритетном режиме.

Как правило, этот тип обмена (обязательный к поддержке всеми модулями) используется для конфигурирования устройств или настройки формата PDO объектов.

Обмен на основе PDO объектов, используется для синхронной (цикличной или ацикличной) или асинхронной (инициируемый внешними прерываниями) скоростной передачи.

Длина кадра не более 8 байт (длина поля данных фрейма CAN).

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

NMT-мастер занимается администрированием сети. Он инициализирует устройства, обеспечивает контроль ошибок, а также производит их периодическую "перекличку" (Life Guarding) с помощью PDO сообщений (Node Guarding Object) для выявления нерабочих узлов.

Для максимального упрощения процесса интеграции модулей независимых производителей в единую сеть в CANopen используется концепция профилей. К настоящему времени завершено формирование следующих профилей устройств:

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

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

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

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

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

CAN Kingdom

Протокол шведской компании KVASER-AB занимает особое место среди CAN HLP не только из-за своего необычного названия (CAN королевство), но и в значительной степени благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе.

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

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

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

Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип: "Модули обслуживают сеть" (MSN Modules Serves the Network) в отличие от принципа "Сеть обслуживает пользователей" (NSM Network Serves the Modules).

В CAN Kingdom сеть CAN это страна (королевство) со своей столицей (центральный контролирующий узел) и провинциальными городами (остальные узлы).

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

CAN система на базе протокола CAN Kingdom обладает некоторыми особенностями.

· Распределение CAN идентификаторов контролируется разработчиком.

· Максимальное время прохождения любого сообщения в сети предсказуемо.

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

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

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

· В сеть CAN Kingdom возможна интеграция любых CAN-модулей, включая разработанных для других протоколов, например, DeviceNet или SDS.

· Не существует каких-либо рекомендуемых скоростей передачи данных. Но за первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 кбит/с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.

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

· Правила идентификации модулей основаны на использовании международного кода EAN/UPC, включающего код производителя и продукта.

· Гибкость режимов передачи и упаковки данных (включая использование поля арбитража для передачи данных).

· Объединение узлов в группы.

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

DeviceNet

DeviceNet протокол, разработанный в 1994 году компанией Allen-Bradley корпорации Rockwell.

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

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

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

Сеть DeviceNet имеет шинную топологию с отводами.

Физической средой передачи является 4-проводной кабель (CAN_H, CAN_L, Vcc, Ground), причем возможны две его разновидности: толстый (внешний диаметр 12,2 мм) и тонкий (6,9 мм).

Определены лишь три значения скорости передачи данных 125, 250 и 500 кбит/с.

Максимальные длины центральной магистрали и отводов в зависимости от скорости передачи и типа кабеля приведены в таблице 3.11.

Таблица 3.11 − Ограничения на протяженность сети DeviceNet

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

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

Сеть DeviceNet допускает "горячее" (без обесточивания сети) подключение и отключение модулей.