Сеть CAN: популярные прикладные протоколы

Выпущенный из недр автомобилестроительных лабораторий полтора десятка лет назад, джин CAN-технологий (CAN — Controller Area Network) стремительно проникает буквально во все сферы человеческой деятельности — от домашнего хозяйства до орбитальных космических станций. Общее число CAN-сетей, которые будут установлены в мире в текущем году, по прогнозам ассоциации CiA (CAN in Automation, www.can-cia.de) должно составить около 83 млн. (против 11 млн. в 96 году), а в 2000 году — превысить 125 млн. На родине CAN-технологий — в Германии — CAN-шина устойчиво держит первое место по популярности на фоне всех прочих стандартов полевых шин.
    Среди многочисленных факторов, обеспечивших взлет популярности CAN в последние годы, следует отметить разнообразие элементной базы CAN (от десятков ведущих производителей полупроводников — Intel, Philips, Siemens, Motorola и др.), ее дешевизну (простейшие устройства ввода/вывода — CAN SLIO (2.0А) стоят менее доллара), гарантированную доступность в течение не менее 10 лет. Это высокая степень и надежности, и “живучести” сети благодаря развитым механизмам обнаружения ошибок (одна незамеченная ошибка за тысячу лет при ежедневной 8-часовой работе сети на скорости 500 кбит/с), повтору ошибочных сообщений, самоизоляции неисправных узлов, иммунитету к электромагнитным помехам. Немалую роль играет и возможность поддержки разнотипных физических сред передачи данных — от дешевой витой пары до оптоволокна и радиоканала. А ряд оригинальных механизмов сетевого взаимодействия (мультимастерность, широковещание, побитовый арбитраж) в сочетании с высокой скоростью передачи данных (до 1 Мбит/с) способствуют эффективной реализации режима реального времени в системах распределенного управления.
    Однако сетевых сервисов спецификации Robert Bosch CAN Specification 2.0A/B и международного стандарта ISO 11898 зачастую явно недостаточно для эффективной разработки CAN-сетей. Дело в том, что упомянутые документы описывают лишь два самых нижних уровня эталонной (семиуровневой) модели взаимосвязи открытых систем OSI/ISO — физический и канальный (рис. 1). Определены форматы сообщений, процессы передачи данных длиной до 8 байт, механизмы обнаружения ошибок, некоторые физические параметры среды передачи данных (только в ISO 11898) и др. Но “за кадром” остаются такие важные на этапе разработки моменты, как адресация узлов, распределение между ними CAN-идентификаторов, интерпретация содержимого фрейма данных, передача данных длиной более 8 байт и др. Поэтому с началом массового выпуска CAN-компонентов и широкого распространения CAN-приложений рядом независимых компаний и некоммерческих ассоциаций в области систем промышленной автоматизации, транспорта и т. д. проводилась (и продолжается по сей день) работа по созданию и стандартизации спецификаций протоколов верхнего уровня — HLP (Higher Level Protocol) для CAN-сетей.

Рис. 1. Эталонная модель OSI/ISO и спецификации CAN

Как правило, большинство существующих на сегодня CAN HLP имеет сжатую трехуровневую архитектуру (рис. 1), включающую два базовых уровня (физический, часто дополненный более конкретными спецификациями, и канальный) CAN-протокола и прикладной. Сервисы промежуточных уровней либо отсутствуют, либо включены в него. Уменьшенное число уровней против полных семи позволяет обеспечить предсказуемость задержек прохождения сообщений в сети и повысить ее производительность в режиме реального времени.
    При разработке CAN-приложений на базе стандартных прикладных протоколов разработчик получает в руки уже готовые механизмы передачи данных любой длины, процедуры начальной инициализации, распределения идентификаторов и т. п. Появляется возможность простой интеграции стандартных модулей независимых производителей и наращивание сети в будущем, а так-же максимально полной реализации основных преимуществ CAN протокола, особенно при работе в режиме реального времени. И наконец, многочисленные группы и ассоциации пользователей и производителей оборудования под те или иные прикладные протоколы, широко представленные в Интернете множеством сайтов, значительно облегчают нелегкую жизнь системного разработчика.
    К настоящему времени известно уже более четырех десятков CAN HLP. Среди подобного многообразия CAN HLP наибольшее распространение, в особенности в системах промышленной автоматизации, получили четыре, поддерживаемых ассоциацией CiA и рассмотренных ниже. Это CAL/CANopen, CAN Kingdom, DeviceNet и SDS (Smart Distributed System).

CAL/CANopen

Разработка и поддержка открытого протокола прикладного уровня для сетей промышленной автоматизации были одними из приоритетных целей создания организации CiA в 1992 году. Основой такого протокола послужил HLP, разработанный фирмой Philips, после доработки и усовершенствования которого рабочей группой CiA, в 1993 году была опубликована спецификация CAL — CAN Application Level (CiA DS 20x). Фундаментом CAL служит канальный уровень CAN. CAL не является ориентированным на конкретные приложения стандартом протокола, не содержит каких-либо профилей, привязанных к конкретным устройствам, и не определяет содержание передаваемых данных, но предлагает стандартизованные элементы сетевого сервиса прикладного уровня. CAL включает в себя четыре составные части:

• Спецификация CAN сообщений (CMS — CAN Message Specification);
  
• Сетевое управление (NMT — Network Management);
  
• Распределение идентификаторов (DBT — Identifier Distributor);
  
• Управление уровнем (LMT — Layer Management).
  

CMS определяет типы объектов взаимодействия в рамках объектно- ориентированного подхода, правила и механизмы передачи данных разных типов посредством CAN фреймов, включая передачу пакетов длиной более 8 байт. Сетевое управление построено на взаимодействии типа мастер-слуга. Один модуль сети является NMT-мастером, все остальные — NMT-ведомые. NMT-мастер инициализирует, управляет NMT- слугами, которые желают принять участие во взаимодействии, и позволяет им общаться между собой посредством CMS-сервисов. Также в задачи сетевого управления входят контроль ошибок и конфигурирования устройств. Благодаря DBT-сервисам происходит бесконфликтное распределение идентификаторов среди модулей под контролем DBT-мастера. Посредством LMT-сервисов возможны запрос и изменение текущих параметров (значений идентификаторов , скорости передачи, битового квантования и т. п.) в модулях непосредственно из CAN-сети.
    Сетевые CAN приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, в промышленном оборудовании.
    Результатом дополнения CAL (точнее, некоторого его подмножества) системой профилей (устройств, интерфейсов, приложений и т. д.) и спецификациями физического уровня (типы соединителей, правила битового квантования и т. д.) явилось появление более “конкретного” стандарта протокола CANopen. По существу CANopen является приложением прикладного уровня CAL. Первоначально CANopen предназначался для сетей управления движущимися механизмами в системах промышленной автоматики. Однако впоследствии протокол нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий.
    CANopen базируется на двух уровнях стандарта CAN (ISO 11898, Bosch CAN Specification 2.0 A/B). В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных — двухпроводная дифференциальная линия), CANopen содержит собственные правила битового квантования, а также определяет три рекомендуемых типа соединителей:

• 9-контактный D-Sub (DIN 41652);
  
• 5-контактный круглый Mini (ANSI/B93.55M-1981);
  
• 5-контактное открытое клеммное соединение.
  

Разводкой контактов для всех типов соединителей предусмотрена возможность подачи питания на трансиверы узлов, имеющих гальваническую развязку. В сети CANopen определены восемь градаций скоростей передачи данных: 1 Мбит/с, 800 кбит/с, 500, 250, 125, 50, 20 и 10 кбит/с. Поддержка скорости 20 кбит/с является обязательной для всех модулей.
    Прикладной уровень представляет собой подмножество CAL и основано на 4-х его сервисных элементах — CMS, NMT, DBT и LMT, дополненных профилем соединения (CiA DS 301), определяющим базовые правила обмена данными и структуру словаря объектов. Более развитые механизмы сетевого взаимодействия для интеллектуальных устройств (человеко-машинные интерфейсы — HMI, PC-контроллеры, PLC, инструментальные средства и т. п.) описаны в дополнении к коммуникационному профилю (CiA DS 302).
    В сети CANopen на прикладном уровне модули обмениваются между собой объектами- сообщениями — COB (Communication Object), включающими в себя один или более CAN фреймов. Всего существует четыре типа таких объектов:

• данных процесса — Process Data Objects (PDO);
  
• сервисных данных — Service Data Object (SDO);
  
• специальных функций — Special Function Objects;
  
• сетевого управления — Network Management Objects.
  

 SDO-объекты позволяют модулям обмениваться данными любого объема (при последовательностях более 8 байт — благодаря использованию нескольких CAN фреймов) в ацикличном низкоприоритетном режиме. Как правило, этот тип обмена (обязательный к поддержке всеми модулями) используется для конфигурирования устройств или настройки формата PDO объектов. В противоположность SDO типу, обмен на основе PDO объектов используется для синхронной (цикличной или ацикличной) или асинхронной (инициируемый внешними прерываниями) скоростной передачи не более 8 байт (длина поля данных фрейма CAN), имеет более высокий приоритет, чем SDO и применяется для пересылок данных в режиме реального времени. Объекты специальных функций служат для выполнения ряда специальных задач: запуска синхронных процессов, передачи значения абсолютного времени и кодов ошибок. Объекты сетевого управления включают сообщения NMT, LMT и DBT сервисов.
    Администрированием сети занимается NMT-мастер, который инициализирует устройства, обеспечивает контроль ошибок, а также производит их периодическую “перекличку” (Life Guarding) с помощью PDO сообщений (Node Guarding Object) для выявления узлов, находящихся в нерабочем состоянии ввиду физического отсутствия или отключения от шины (bus off) по счетчику ошибок.
    Для максимального упрощения процесса интеграции модулей независимых производителей в единую сеть в CANopen используется концепция профилей. К настоящему времени завершено формирование следующих профилей устройств:

• Модули ввода/вывода (аналоговые и цифровые) (DSP-401);
  
• Приводы и модули управления перемещением (DSP-402);
  
• Элементы человеко-машинного интерфейса (DSP-403);
  
• Измерительные устройства и регуляторы (WD-404);
  
• Кодеры (DSP-406).
  

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

CAN Kingdom

Протокол шведской компании KVASER-AB (www.kvaser.se) занимает особое место среди CAN HLP не только из-за своего необычного названия (CAN королевство), но и в значительной степени благодаря оригинальной концепции сетевого взаимодействия и эффективности CAN-приложений на его основе. Началу работ над первой версией (текущая — третья) протокола CAN Kingdom в 1990 году предшествовал многолетний опыт компании в области создания систем распределенного управления. Протокол был специально разработан для управления движущимися машинами и механизмами — промышленными роботами, текстильными станками, мобильными гидравлическими устройствами, — и позволяет достичь высокой производительности в режиме реального времени при удовлетворении жестких требований безопасности. CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике — от надувных лодок и систем наведения на цели до сверхзвуковых истребителей и ракет.
    Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей от независимых производителей. CAN Kingdom не является “готовым” протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов — метапротокол, — с помощью которых можно “собрать” протокол под конкретную сеть модулей. Этим достигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью “закрытости” оригинального протокола.
    При разработке спецификации CAN Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI/ISO, поскольку семиуровневая модель OSI/ISO создавалась изначально для описания традиционных компьютерных сетей, от которых не требуется работа в реальном масштабе времени, и предназначены они для обслуживания пользователей, требования которых априори (на этапе построения такой сети) неизвестны и непредсказуемы. В системах же управления реального времени ситуация прямо противоположная — на стадии разработки все коммуникационные потребности модулей должны быть известны.

Рис. 2.
а) Традиционное представление CAN-сети и
б) в терминах CAN Kingdom

Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип: “Модули обслуживают сеть” (MSN — Modules Serves the Network) в отличие от принципа “Сеть обслуживает пользователей” (NSM — Network Serves the Modules), свойственного компьютерным сетям.
    Представление CAN сети в терминах CAN Kingdom (в сравнении с традиционным) дано на рис. 2. В CAN Kingdom сеть CAN — это страна (королевство) со своей столицей (центральный контролирующий узел) и провинциальными городами (остальные узлы). Король (управляющая программа-супервизор) управляет всем королевством и отвечает за соблюдение закона и порядка в нем, а за местное управление (в пределах своего узла) отвечают мэры городов (управляющие программы узлов). Каждый город экспортирует или импортирует продукцию — информацию — посредством почты, которая циркулирует по почтовому тракту (CAN-шина) и проходит через почтмейстеров (CAN контроллеры). Типы почтовой корреспонденции (информация, передаваемая по сети) и ее соответствие CAN-терминам таковы:

Письмо	CAN-фрейм(данных или удаленного запроса)
Конверт	CAN-идентификатор
Страница	Поле данных CAN-фрейма
Строка	Байт данных
Элемент строки	Бит данных

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

• Распределение CAN идентификаторов находится под полным контролем разработчика.
  
• Максимальное время прохождения любого сообщения в сети предсказуемо.
  
• Во время начальной инициализации системы происходит обязательный этап настройки (setup) протокола, включая построение форматов данных, начиная с битового уровня, методов управления шиной, распределение идентификаторов и т. д.
  
• В системе всегда должен присутствовать (как минимум до завершения настройки протокола) супервизор (Король) , производящий инициализацию системы, контроль подключенных узлов и т. д. Ни один модуль не может принимать участие в сетевом обмене без разрешения Короля.
  
• Перед инициализацией сети каждый модуль (город) должен иметь свой номер (CAN Kingdom не описывает конкретный способ установки номера модуля — это может быть DIP-переключатель, энергонезависимая память или конфигурация соединителя) и “знать” идентификатор сообщения инициализации (королевское письмо) и скорость передачи данных в сети.
  
• В сеть CAN Kingdom возможна интеграция любых CAN-модулей, включая разработанных для других протоколов, например, DeviceNet или SDS.
  
• Не существует каких-либо рекомендуемых скоростей передачи данных. Но за первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 кбит/с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.
  

Наличие одного центра-Короля, который содержит всю информацию о системе, избавляет от использования профилей устройств, часто применяемых в других HLP.
    Правила идентификации модулей основаны на использовании международного кода EAN/UPC, включающего код производителя и продукта. Среди других особенностей CAN Kingdom можно отметить гибкость режимов передачи и упаковки данных (включая использование поля арбитража для передачи данных), объединение узлов в группы, поддержка часов реального времени, различных режимов доступа к шине.

DeviceNet

DeviceNet — протокол, разработанный и опубликованный в 1994 году компанией Allen-Bradley (www.ab.com) корпорации Rockwell и впоследствии переданный в ведение специально организованной для его поддержки ассоциации ODVA (Open DeviceNet Vendor Association Inc., www.odva.org). DeviceNet — недорогое, простое и эффективное решение для объединения разнообразных устройств промышленной автоматизации независимых производителей в единую систему: фото-, термодатчики, стартеры, считыватели штриховых кодов, элементы человеко-машинного интерфейса — клавиатуры, дисплейные панели, — наряду с управляющими устройствами — PLC, компьютерами и т. д. (рис. 3). При разработке протокола помимо снижения стоимости также стояла задача упрощения и унификации диагностики подобных устройств. Первые устройства, удовлетворяющие спецификации DeviceNet, появились на рынке в начале 1995 года. DeviceNet также построен на двух нижних уровнях стандарта CAN, дополненных более детальными, чем в других HLP, спецификациями физической среды.

Рис. 3. Пример сети DeviceNet

Сеть DeviceNet имеет шинную топологию с отводами. Физической средой передачи является 4-проводной кабель (CAN_H, CAN_L, Vcc, Ground), причем возмож-ны две его разновидности: толстый (внешний диаметр 12,2 мм) и тонкий (6,9 мм). Определены лишь три значения скорости передачи данных — 125, 250 и 500 кбит/с. Максимальные длины центральной магистрали и отводов в зависимости от скорости передачи и типа кабеля приведены в табл. 1.

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

Важной особенностью сети DeviceNet является возможность питания модулей непосредственно от сетевого кабеля (24 В, до 8 А на толстом кабеле), а также допускается применение нескольких источников питания в любой точке шины. Все это дает возможность построения автономной сети, не зависящей от наличия или качества внешнего питания, а при необходимости позволит легко демонтировать и снова развернуть систему на новом месте. Сеть DeviceNet допускает “горячее” (без обесточивания сети) подключение и отключение модулей.
    Стандарт DeviceNet содержит также подробное описание многочисленных типов переходников, разветвителей (одиночных и многопортовых), соединителей (Mini, Micro), сетевых отводов и т. п.
    При описании организации типов данных, сетевого поведения модулей в DeviceNet используется объектно-ориентированная модель. Обязательные классы объектов включают в себя следующие:

• объект удостоверения (Identity object). Содержит информацию о модуле (код производителя, продукта, версия и т. п.);
  
• объект соединения (Connection object). Логический порт ввода/вывода устройства;
  
• объект DeviceNet. Включает MAC ID (идентификатор модуля), скорость передачи, состояние модуля и т. п;
  
• объект роутера сообщения (Message router object). Перенаправляет явное сообщение получателю.
  

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

• сообщения ввода/вывода (I/O messages) — предназначены для целей управления устройствами и передачи данных в реальном времени между узлами в широковещательном или в режиме точка-точка. Используют идентификаторы с высоким приоритетом, которые и определяют содержание сообщения;
  
• явные сообщения (Explicit messages) — для многоцелевого обмена данными в режиме точка- точка. Обеспечивают типичный сервис запрос/ответ. Используют идентификаторы с низким приоритетом и применяются обычно для конфигурирования устройств и целей диагностики. Значение сообщения содержится в поле данных.
  

При необходимости передачи данных длиной более 8 байт применяется механизм фрагментации. В зависимости от потребностей обмена и возможностей модулей, возможны мастер-слуга (master-slave), мультимастерный (multi-master), или равноправный (peer to peer) способы взаимодействия устройств. Пересылки данных могут инициироваться путем опроса, циклически или по изменении их значения (change of state). Максимальное число узлов в сети DeviceNet — 64.
    Модули в сети могут быть как UMCC-типа (UnCon-nected Message Manager), способные выставлять равноправные (peer to peer) соединения с другими модулями, так и Predefined Master/Slave- типа, требующие меньшей длины кода и производительности управляющего микроконтроллера, но которые не могут произвольно выбирать путь соединения, и их объекты соединения конфигурируются при включении устройства.
    Для обеспечения “стыкуемости” устройств разных производителей и их взаимодействия в рамках единой сети стандарт DeviceNet, подобно многим HLP, определяет ряд профилей устройств. Формированием библиотек профилей занимаются специальные группы (Special Interest Groups) ассоциации ODVA.

SDS (Smart Distributed System)

SDS — разработка компании Honeywell Inc. (Micro Switch Division, www.honeywell.sensing.com). Наряду со стандартом DeviceNet, SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальными датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации.
    По степени завершенности — от спецификаций физической среды до прикладного уровня, — ориентировке на снижение стоимости, SDS-стандарт напоминает DeviceNet.
    Шинная топология представляет собой линейную шину (магистраль или транк) с короткими отводами (рис 4). Определены два базовых типа кабельной разводки: Mini (применяемый при сборке транка сети) — 4-проводной кабель с максимальной токовой нагрузкой 8 А, 5-контактный разъем — и Micro (для подключения физических устройств к сети) — 4-проводной кабель, 3 А, 4-контактный разъем без отдельного контакта для экрана кабеля.

Рис. 4. Пример сети SDS

В сети SDS допускается и обычная проводная разводка с использованием открытых клеммных соединителей. Всеми типами кабельной разводки и соединителей, также как и в сети DeviceNet, предусмотрено подведение питающего напряжения (диапазон 11–25 В на стороне устройства) к узлам. Предельные значения длин магистрали и отводов сети SDS в зависимости от скоростей (их четыре) передачи приведены в табл. 2.

Таблица 2. Предельные значения длин магистрали и отводов сети SDS

Сообщения, циркулирующие в сети SDS, носят название APDU (Application layer Protocol Data Unit) — блоки данных протокола прикладного уровня. APDU представляет собой CAN фрейм стандартного формата (расширенный формат фрейма в SDS-сети не применяется), элементы которого имеют свое собственное назначение в SDS. APDU имеет две формы — укороченную (не используется при передаче данных и содержит в поле DLC нули) и длинную.
    При необходимости передачи последовательностей данных более 6 байт используется фрагментированный формат (до 64 фрагментов по 4 байт) длинной формы APDU.
    Укороченная форма APDU используется в следующих сервисах прикладного уровня:

• Change of State (OFF, ON, OFF ACK, ON ACK) — обнаружение изменения состояния логического устройства;
  
• Write (ON State, OFF State, ON State ACK, OFF State ACK) — управление состояниями логического устройства.
  

К сервисам, использующим длинную форму APDU, относятся:

• Channel — обеспечивает как широковещательный (multicast), так и равноправный (peer to peer) каналы соединения;
  
• Connection — открытие/закрытие индивидуальных типов соединения;
  
• Write — чтение атрибутов объектов устройства;
  
• Read — изменение атрибутов объектов устройства;
  
• Action — команда объекту устройства выполнить действие;
  
• Event — сигнализация о событии объектом устройства.
  

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

• Запрос (Request) — генерация APDU устройством-инициатором соединения;
  
• Ответ (Response) — ответный APDU устройства-ответчика;
  
• Индикация (Indication) — фиксация факта приема APDU устройством-ответчиком;
  
• Подтверждение (Confirm) — подтверждение приема APDU устройством-инициатором.
  

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

Заключение

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

E-mail: say@tande.com