Протоколы прикладного уровня CAN-сетей
CAL/CANopen.Фундаментом CAL служит канальный уровень CAN. CAL не является ориентированным на конкретные приложения стандартом протокола, не содержит каких-либо профилей, привязанных к конкретным устройствам или задачам, и не определяет содержание передаваемых
данных, но предлагает стандартизованные элементы сетевого сервиса прикладного уровня. Решение же вопроса, какую часть из них использовать, находится в ведении разработчика. CAL включает в себя четыре составные части:
· спецификацию CAN-сообщений (CMS – CAN Message Specification);
· сетевое управление (NMT - Network Management);
· распределение идентификаторов (DBT - Identifier Distributor);
· управление уровнем (LMT - Layer Management).
Спецификация CMS описывает типы объектов взаимодействия в рамках объектно-ориентированного подхода, правила передачи данных разных типов посредством CAN-фреймов, взаимодействие между модулями в терминах модели клиент-сервер, механизмы передачи данных, включая передачу пакетов длиной более 8 байтов. Сетевое управление построено на взаимодействии типа master-slave. Один модуль сети является NМТ-мастером, все остальные – NMT-ведомые. Посредством сервисов управления NMT-мастер инициализирует, управляет NMT-ведомыми, которые желают принять участие во взаимодействии, и позволяет им общаться между собой посредством CMS-сервисов. Также в задачи сетевого управления входят контроль ошибок и конфигурирования устройств. Благодаря DBT-сервисам происходит бесконфликтное распределение идентификаторов среди модулей под контролем DBT-мастера. Посредством LMT-сервисов возможны запрос и изменение текущих параметров (значений идентификаторов, скорости передачи, битового квантования и т.п.) в модулях непосредственно из CAN-сети.
|
|
|
Сетевые CAN-приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контроля дорожного движения, на транспорте, в промышленном оборудовании.
CANopen.CANopen является одним из приложений прикладного уровня CAL, но единственным приложением подобного рода, поддерживаемым ассоциацией CiA. Профили устройств (CiA DS 40х) упрощают интеграцию модулей разных производителей в единую сеть, a определение минимального обязательного (mandatory) набора свойств модулей гарантирует работоспособность системы на базовом уровне.
Первоначально CANopen предназначался для сетей управления движущимися механизмами в системах промышленной автоматики. Однако впоследствии он нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий.
Структура CANopen в соответствии с моделью OSI приведена на
рис. 6.26. Два нижних уровня соответствуют стандарту CAN (ISO 11898, CAN Specification 2.0 А/В). В дополнение к спецификациям физического уровня ISO 11898 (среда передачи данных – экранированная или неэкранированная двухпроводная дифференциальная линия) CANopen содержит собственные правила битового квантования, a также определяет три рекомендуемых типа соединителей:
|
|
|
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 кбит/с является обязательной для всех модулей.
|
|
|
|
 |
Прикладной уровень представляет собой некоторое подмножество CAL и базируется на четырех его основных сервисных элементах; CMS, NMT, DBT и LMT, дополненных профилем соединения (CiA DS 301), определяющим базовые правила обмена данными и структуру словаря объектов. Более развитые механизмы сетевого взаимодействия для интеллектуальных устройств (человеко-машинные интерфейсы – HMI, РС-контроллеры, PLC, инструментальные средства и т.п.) описаны в дополнении к коммуникационному профилю (CiA DS 302).
|
|
|
|
В сети CANopen на прикладном уровне модули обмениваются между собой объектами-сообщениями – COB (Communication Object), включающими в себя один или более CAN-фреймов. Всего существует четыре типа таких объектов:
· объекты данных процесса — Process Data Objects (PDO);
· объекты сервисных данных — Service Data Object (SDO);
· объекты специальных функций — Special Function Objects;
· объекты сетевого управления — Network Management Objects.
Собственно для целей передачи данных используются два различных механизма – с использованием PDO и на основе SDO. SDO позволяет модулям обмениваться данными любого объема (при последовательностях более 8 байтов – благодаря использованию нескольких CAN-фреймов) в ацикличном низкоприоритетном режиме. Как правило, этот тип обмена используется для конфигурирования устройств или настройки формата PDO. Любое устройство, интегрируемое в сеть CANopen, должно обязательно поддерживать SDO-обмен. В противоположность SDO-типу обмен на основе PDO используется для синхронной (цикличной или ацикличной) или асинхронной (инициируемой внешними прерываниями) скоростной передачи не более 8 байтов (длина поля данных фрейма CAN), имеет более высокий приоритет, чем SDO, и применяется для пересылок данных в режиме реального времени. Различия между этими двумя типами передачи данных подобны разнице между тяжелым грузовиком и быстрым, легким спортивным автомобилем.
|
|
|
Для выполнения специальных задач, в том числе диктуемых спецификой режима реального времени, служат объекты специальных функций:
· синхронизации – Synchronization Object (SYNO) – служит для запуска синхронных процессов;
· временных маркеров – Tone 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).
Отдельного упоминания заслуживает профиль приложения WD-407 (IBIS-CAN) CAN-сетей в области управления электроникой на общественном транспорте (где CAN-сети вообще используются довольно интенсивно по всей Европе): билетный контроль, подсчет пассажиров, информационные панели и т.п.
CAN Kingdom.Протокол был специально разработан для управления машинами и механизмами (промышленные роботы, текстильные станки, мобильные гидравлические устройства), позволяет удовлетворить такие свойственные подобным приложениям требования, как:
· эффективность функционирования в режиме реального времени;
· жесткие требования безопасности;
· высокая общая производительность.
CAN Kingdom является также основой американского военного стандарта СDА 101 и широко используется в военной технике: от надувных лодок и систем наведения на цели до сверхзвуковых ракет и истребителей.
Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей независимых производителей. CAN Kingdom, скорее, набор примитивов – метапротоколов, с помощью которых можно «собрать» протокол для конкретной сети модулей. Это позволяет достичь уникального сочетания простоты интеграции готовых модулей с высокой степенью «закрытости», защищенности оригинального протокола.
При разработке спецификации CAN Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI. В системах управления реального времени на стадии разработки все коммуникационные потребности модулей должны быть известны. И готовая сеть должна функционировать точно так, как задумал системный разработчик. Краеугольным камнем концепции сетевого взаимодействия CAN Kingdom является принцип «Модули обслуживают сеть» (MSN – Modules Serves the Network), в отличие от принципа «Сеть обслуживает пользователей» (NSM – Network Serves the Modules), свойственного компьютерным сетям.
На этапе разработки сеть CAN Kingdom приспосабливается к нуждам системы, что становится возможным благодаря априорным знаниям о потребностях системы, где детерминизм функционирования модулей является условием обеспечения требований режима реального времени (необходимо, к примеру, знать, как долго сообщение может следовать от одного узла к другому).
Следствием принципа MSN также является и то, что в сети CAN Kingdom всегда должен существовать один модуль-супервизор, содержащий всю информацию о системе и ответственный за ее инициализацию.
|
Рис. 6.27. Структура CAN-сети
Представление CAN-сети в терминах CAN Kingdom (в сравнении с традиционным взглядом) дано на рис. 6.27. В CAN Kingdom управляющая программа-супервизор управляет всем оборудованием и отвечает за соблюдение устойчивого функционирования, a за управление в пределах своего узла отвечают управляющие программы узлов. Каждый узел передает информацию посредством почты, которая циркулирует по почтовому тракту (CAN-шина) и проходит через CAN-контроллеры. Типы информации, передаваемой по сети, и ее соответствие CAN-понятиям даны в
табл. 6.5.
Таблица 6.5
Дата добавления: 2018-06-27; просмотров: 295; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!