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

Протоколы прикладного уровня сетей 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-сети вообще используются довольно интенсивно по всей Европе): билетный контроль, подсчет пассажиров, информационные панели и т. п.

Дата добавления: 2015-07-02