CAN HLP протоколы

January 13, 2011 by admin Комментировать »

К настоящему времени известно уже более четырех десятков CAN HLP. Среди CAN HLP наибольшее распространение в системах промышленной автоматизации получили четыре, поддерживаемых ассоциацией CiA: CAL/CANopen, CAN Kingdom, DeviceNet и SDS.

CAL/CANopen. 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- ведомыми, которые принимают участие во взаимодействии, и позволяет им общаться между собой посредством 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) в отличие от принципа "Сеть обслуживает пользователей" (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 могут быть двух типов:

•                 Сообщения ввода/вывода (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 – команда объекту устройства выполнить действие;

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

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

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

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

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

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

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

Оставить комментарий

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