Необходимость и многообразие HLP CAN.

На прошлой лекции мы с Вами познакомились с CAN (Control Area Network) – дешевой, удобной, понятной и открытой, надёжной, вобщем, простой и эффективной промышленной коммуникационной технологией.

Как Вы помните, собственной стандарт CAN определяет только два нижних уровня модели ISO/OSI (рис. 7.1).

Рис. 1. Соотношение эталонной модели OSI/ISO и CAN_протоколов Устройство CAN интерфейса ADAM_5000/CAN фирмы Advantech, оддерживающее протоколы CANopen и DeviceNet

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

Разумеется, сервисов двух нижних уровней может оказаться вполне достаточно, когда речь идет о разработке сравнительно простой сети, не планируемой к расширению и вдобавок состоящей из созданных под нее узлов и модулей. Или, к примеру, стоит задача создать «закрытую» сеть на основе оригинального протокола. Но в подавляющем большинстве случаев практических СAN-разработок двух «стандартных» уровней оказывается явно мало, а изобретение своего протокола для конкретной задачи — слишком дорогое, долгое и, следовательно, малоэффективное занятие. Поэтому с самого начала опубликования CAN-спецификаций и выпуска первых CAN-компонентов как независимыми компаниями, так и ассоциациями по промышленной автоматизации непрерывно велась и продолжается до сих пор работа над созданием спецификаций протоколов верхнего уровня — HLP (Higher Level Protocol) для СAN-сетей. Уже разработанные и существующие в настоящее время спецификации протоколов CAN HLP, как правило, имеют сжатую трехуровневую архитектуру (рис. 1). Сервисные функции промежуточных уровней либо отсутствуют, либо включены в прикладной. Соблюдение полной иерархии уровней эталонной модели OSI/ISO в системах управления не требуется, кроме того, наличие дополнительных изолирующих межуровневых интерфейсов привело бы к потере производительности системы в режиме реального времени.

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

Во-первых, в отличие от использования только сервисов ISO 1898 или Bosch 2.0 A/B, вместе с тем или иным HLP разработчик получает уже готовые механизмы передачи данных любой длины, процедуры начальной инициализации, распределения идентификаторов и т. п., а кроме этого, часто и конкретную спецификацию физической среды для своей области применения: длина и топология шины, скорости передачи, типы кабелей, соединителей. На подготовку и тестирование такой спецификации в реальных условиях уже потрачены силы большого числа разработчиков и экспертов.

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

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

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

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

Среди многообразия CAN HLP, представленных на современном рынке CAN-технологий, особого внимания заслуживают четыре получивших наибольшее распространение в последнее время. Это СAL/CANopen, CANKingdom, DeviceNet и SDS (SmartDistributed System).

2. CAL/CANopen.

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

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

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

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

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

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

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

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

Сетевое управление построено на взаимодействии типа master-slave. Один модуль сети является NMT-мастером, все остальные — NMT-ведомые. Посредством сервисов управления NMT-мастер инициализирует, управляет NMT-ведомыми, которые желают принять участие о взаимодействии, и позволяет им общаться между собой посредством СMS-сервисов. Также в задачи сетевого управления входят контроль ошибок и конфигурирования устройств.

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

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

Результатом дополнения CAL системой профилей (устройств, интерфейсов, приложений и т. д.) и спецификациями физического уровня (типы соединителей, правила битового квантования, определяющие, насколько квантов разделять бит и в каком месте бита считывать его значение, и т. д.) явилось появление более детализированного стандарта протокола CANopen. По существу, CANopen является одним из приложений прикладного уровня CAL, но единственным приложением подобного рода, поддерживаемым ассоциацией СiA. Профили устройств (CiA DS 40x) упрощают интеграцию модулей разных производителей в единую сеть, а определение минимального обязательного (mandatory) набора свойств модулей гарантирует работоспособность системы на базовом уровне. Первоначально CANopen предназначался для сетей управления движущимися механизмами в системах промышленной автоматики. Однако впоследствии он нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий.

Структура CANopen в соответствии с моделью OSI приведена на рис. 7.2. Два нижних уровня соответствуют стандарту CAN (ISO 11898, CAN Specification 2.0 A/B).

Рис. 7.2. Архитектура протокола CANopen

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

1) 9-контактный DSub (DIN 41652),

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

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

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

Прикладной уровень представляет собой некоторое подмножество CAL и базируется на четырех его основных сервисных элементах: CMS, MT,DBT и LMT, дополненных профилем соединения (CiA DS 301), определяющим базовые правила обмена данными и структуру словаря объектов. Более развитые механизмы сетевого взаимодействия для интеллектуальных устройств (человеко-машинные интерфейсы — HMI, контроллеры, PLC, инструментальные средства и т. п.) описаны в дополнении к коммуникационному профилю (CiA DS302).

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

- объекты данных процесса — Process Data Objects (PDO);

- объекты сервисных данных — Service Data Object (SDO);

- объекты специальных функций — Special unction Objects;

- объекты сетевого управления — Network Management Оbjects.

Собственно для целей передачи данных используются два различных механизма — с использованием PDO и на основе SDO. SDO позволяют модулям обмениваться данными любого объема (при последовательностях более 8 байтов — благодаря использованию нескольких кадров CAN) в нецикличном низкоприоритетном режиме. Как правило, этот тип обмена используется для настройки устройств offline. Любое устройство, интегрируемое в сеть CANopen, должно обязательно поддерживать SDO-обмен.

В противоположность SDO-типу, обмен на основе PDO используется для синхронной или асинхронной скоростной (т.е. в реальном времени) передачи не более 8 байтов (т.е. за 1 кадр CAN). PDO имеет более высокий чем SDO приоритет.

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

- синхронизации — Synchronization Object (SYNC) — служит для запуска синхронных процессов;

- временных маркеров — Time Stamp Object — одержит значение абсолютного времени;

- аварийный — Emergency Object (EMCY) — служит для передачи кодов ошибок модулей.

Объекты сетевого управления включают сообщения сервисов NMT, LMT и DBT. Администрированием сети занимается NMT-мастер, который инициализирует устройства, обеспечивает контроль ошибок, а также производит их периодическую «перекличку» (Life Guarding) с помощью PDO-сообщений Node Guarding Object) для выявления узлов, находящихся в нерабочем состоянии ввиду физического отсутствия или отключения от шины (bus off) по счетчику ошибок.

Устройство в сети CANopen включает в себя три основные логические части:

- интерфейс связи и программное обеспечение протокола;

- словарь объектов;

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

Первая часть обеспечивает прием-передачу объектов по сети. Вторая (словарь объектов) описывает типы данных, объектов связи (COB) и прикладных объектов, используемых в данном устройстве. Третья часть обеспечивает внутреннюю функциональность устройства и взаимодействие с его аппаратным интерфейсом.

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

- модули ввода-вывода (аналоговые и цифровые DSP_401);

- приводы и модули управления перемещением (DSP_402), т.е. наши электропривода;

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

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

- кодеры (DSP_406).

В процессе разработки находятся профили для модулей управления гидравлическими механизмами, дизельными двигателями и железнодорожным транспортом. Кроме этого, существует профиль интерфейса — IEC 1131 (DSP_405). Есть профиль приложения WD_407 (IBIS_CAN) CAN-сетей в области управления электроникой на общественном транспорте (где CAN-сети вообще используются довольно интенсивно по всей Европе): билетный контроль, подсчет пассажиров, информационные панели и т. п.

DeviceNet.

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

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

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

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

Таблица 7.1. Соотношения предельной длины и скоростей передачи данных сети DeviceNet

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

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

Стандарт DeviceNet содержит также подробное описание многочисленных типов переходников, разветвителей (одиночных и многопортовых), соединителей, сетевых отводов и т. п. В елях еще большего снижения стоимости системы на базе сети DeviceNet фирмой Allen_Bradley был предложен новый тип кабельной разводки на основе 4-проводного плоского кабеля — KwikLink.

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

- объект удостоверения (Identity object) содержит информацию о модуле (код производителя, продукта, версия и т. п.);

- объект соединения (Connection object) — логический порт ввода-вывода устройства;

- объект DeviceNet включает MAC ID (идентификатор модуля), скорость передачи, состояние модуля и т. п.;

- объект сообщения (Message router оbject) перенаправляет явное сообщение получателю.

При передаче данных в сети DeviceNet эффективно используется принцип адресации CAN-протокола с ориентацией на потребителя, узлы выбирают «свои» передаваемые в сети данные по их идентификаторам. Всего определены два типа сообщений:

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

- явные сообщения (Explicit messages)предназначены для многоцелевого обмена данными в режиме «точка-точка» и обеспечивают типичный сервис «запрос-ответ». Используют идентификаторы с низким приоритетом и применяются обычно для конфигурирования устройств и целей диагностики. Значение сообщения содержится в поле данных.

При необходимости передачи данных длиной более 8 байтов применяется механизм фрагментации. В зависимости от потребностей обмена и возможностей модулей возможны «мастер-ведомый» (master_slave), мульти-мастерный (multi-master) или равноправный (peer-to-peer) способы взаимодействия устройств.

Пересылки данных могут инициироваться путем опроса, циклически или при изменении их значения (change of state). Максимальное число узлов в сети DeviceNet — 64. Такое ограничение связано с 6-разрядным двоичным форматом идентификатора модуля MAC ID (он является частью CAN ID, причем в DeviceNet спользуется только стандартный тип кадра CAN с 11-разрядным ID). Однако общее число устройств ввода-вывода может достигать 2048 (по 32 на узел).

Модули в сети могут быть как UCMM-типа (UnConnected Message Manager), способные выставлять равноправные (peer-to-peer) соединения с другими модулями, так и Predefined Master/Slave типа, которые не могут произвольно выбирать путь соединения, и их объекты соединения конфигурируются при включении устройства. Реализация последнего типа модуля требует меньшей длины кода и производительности управляющего микроконтроллера, что снижает общую стоимость устройства.

В сети DeviceNet не всегда устройство с меньшим значением идентификатора модуля — MAC ID выигрывает арбитраж. Это зависит и от того, к какой группе принадлежит сообщение. Всего таких групп четыре (в порядке убывания приоритета):

1) наиболее критичные ко времени доставки сообщения,

2) явные сообщения ввода-вывода для соединения типа Predefined Master/Slave,

3) несрочные сообщения, использующиеся для диагностики и мониторинга,

4) сообщения для offline подключения используются на этапе инсталляции (подключения и настройки) модулей.

Для обеспечения стыкуемости устройств разных производителей и их взаимодействия в рамках единой сети, стандарт DeviceNet, подобно некоторым другим HLP, определяет ряд профилей устройств. Формированием и стандартизацией библиотек профилей занимаются специальные группы (Special Interest Groups) ассоциации ODVA. Более 300 производителей членов ассоциации ODVA занимаются разработкой и производством устройств, инструментальных средств и программного обеспечения для сетей DeviceNet.

Анализ HLP CAN.

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

Далеко не последнюю роль играет поддержка того или иного HLP со стороны производителей CAN-оборудования и инструментальных средств. Сравнивая HLP CAN можно сказать, что самым простым и компактным вариантом объединения несложных промышленных устройств под управлением одного мастера является стандарт SDS. Несколько более развитые сервисы предоставляет спецификация DeviceNet. Наибольшей гибкостью и возможностью максимально эффективной реализации режима реального времени обладает протокол CAN Kingdom. В отличие от других, CANKingdom не касается каких-либо аспектов физического уровня (среда, соединители и т. п.), выходящих за рамки стандарта ISO 11898, и представляет собой высокоуровневую надстройку над канальным уровнем CAN. В таблицу 7.2 сведены некоторые характеристики четырех рассмотренных в статье HLP.

Таблица 7.2. Сравнительные характеристики 4-х HLP CAN

Среди других прикладных CAN-протоколов, получивших признание впоследнее время, можно выделить стандарт SAE J1939 (SAE — Society of Automotive Engineers), пришедший на смену более старому J1708/J1587 и предназначенный для управления в режиме реального времени узлами транспортных средств (грузовики, автобусы), реализующий plug&play режим для модулей и использующий расширенный формат 29-битовый идентификатор) кадра CAN.

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

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