Учебное пособие по интерфейсам систем промышленной автоматизации, страница 28

Вот что могли бы сказать контроллеры, обращаясь в сеть [54]:• фрейм передачи данных: «Привет всем, вот данные с идентификатором Х,получите»;• удалённый фрейм запроса данных: «Привет всем, а может ли кто-нибудьвыслать данные с идентификатором Х?»;• фрейм ошибки: «Стоп, начнем все с начала»;• фрейм перегрузки: «Я очень занят, подождите чуть-чуть».Стандарты протоколов уровня приложений на базе CANКак уже говорилось, CAN-протокол описывает уровень канала данных ичасть физического уровня модели ВОС. Однако этого зачастую недостаточно дляэффективной разработки CAN-сетей. Неопределёнными остаются такие важныена этапе разработки моменты, как адресация узлов, распределение между нимиCAN-идентификаторов, интерпретация содержимого фрейма данных, передачаданных длиной более 8 байт и др. Поэтому с началом массового выпуска CANкомпонентов и широкого распространения CAN-приложений, рядом независимыхкомпаний и некоммерческих ассоциаций в области систем промышленной автоматизации, транспорта и т.д.

проводилась (и продолжается по сей день) работа посозданию и стандартизации спецификаций протоколов верхнего уровня (HigherLevel Protocol, HLP) для CAN-сетей [55].Как правило, большинство существующих на сегодня спецификаций протоколов верхнего уровня для CAN-сетей имеют сжатую трехуровневую архитектуру, включающую два базовых уровня CAN-протокола (физический, часто дополненный более конкретными спецификациями, и канальный) и уровень приложе141ний или прикладной уровень. Сервисы промежуточных уровней либо отсутствуют, либо включены в прикладной уровень. Уменьшенное число уровней противполных семи позволяет обеспечить предсказуемость задержек прохождения сообщений в сети и повысить её производительность в режиме реального времени.При разработке CAN-приложений на базе стандартных прикладных протоколов разработчик получает в руки уже готовые механизмы передачи данных любойдлины, процедуры начальной инициализации, распределения идентификаторов ит.п.

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

Основой такого протокола послужил HLP, разработанный фирмой Philips, после доработки и усовершенствования которого рабочейгруппой CiA, в 1993 году была опубликована спецификация CAL (CANApplication Level –уровень приложений CAN-протокола) (CiA DS 20x, DS от DraftStandard – проект стандарта, англ.) [56]. Фундаментом CAL-протокола служит канальный уровень CAN. CAL не является ориентированным на конкретные приложения стандартом протокола, не содержит каких-либо профилей, привязанных кконкретным устройствам, и не определяет содержание передаваемых данных, нопредлагает стандартизованные элементы сетевого сервиса прикладного уровня.CAL-протокол включает в себя четыре составные части:• спецификация CAN-сообщений (CAN Message Specification, CMS);• сетевое управление (Network Management, NMT);• распределение идентификаторов (Distributor, DBT);• управление уровнем (Layer Management, LMT).Спецификация CAN-сообщений (CMS) определяет типы объектов взаимодействия в рамках объектно-ориентированного подхода, правила и механизмыпередачи данных разных типов, посредством CAN-фреймов, включая передачупакетов длиной более 8 байт.142Сетевое управление построено на взаимодействии типа ведущий – ведомые.Один модуль сети является NMT-мастером, все остальные NMT-ведомые.

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

Посредством LMT-сервисов возможны запрос и изменение текущих параметров (значенийидентификаторов, скорости передачи, битового квантования и т. п.) в модулях непосредственно из CAN-сети.Сетевые CAN-приложения, основанные на прикладном уровне CAL, в настоящее время успешно работают в медицинской электронике, системах контролядорожного движения, на транспорте, в промышленном оборудовании.Протокол CANopen может рассматриваться как приложение прикладногоуровня CAL-протокола. Первоначально CANopen предназначался для сетейуправления движущимися механизмами в системах промышленной автоматики.Однако впоследствии протокол нашел применение в медицине, морской электронике, на транспорте и в системах автоматизации зданий.CANopen базируется на двух уровнях стандарта CAN (ISO 11898, Bosch CANSpecification 2.0 A/B). В дополнение к спецификациям физического уровня ISO11898 (среда передачи данных двухпроводная дифференциальная линия),CANopen содержит собственные правила битового квантования, а также определяет несколько типов используемых соединителей:• 9-контактный D-Sub разъём (DIN 41652);• 15-контактный D-Sub разъём;• разъём RJ-10 (как в телефонах);• разъём RJ-45 (как в Ethernet-сетях);• 5-контактный круглый Mini-разъём;• 5-контактное открытое клеммное соединение и др.Разводкой контактов для всех типов соединителей предусмотрена возможность подачи питания на трансиверы узлов, имеющих гальваническую развязку.

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

п.) описаны в дополнении к коммуникационному профилю (CiA DS 302).В сети CANopen на прикладном уровне модули обмениваются между собойобъектами-сообщениями (Communication Object, COB), включающими в себяодин или более CAN-фреймов. Всего существует четыре типа таких объектов:• объекты данных процесса (Process Data Objects, PDO);• объекты сервисных данных (Service Data Objects, SDO);• объекты специальных функций (Special Function Objects);• объекты сетевого управления (Network Management Objects).SDO-объекты позволяют модулям обмениваться данными любого объёма(при последовательностях более 8 байт благодаря использованию несколькихCAN фреймов) в низкоприоритетном режиме. Как правило, этот тип обмена (обязательный к поддержке всеми модулями) используется для конфигурированияустройств или настройки формата PDO-объектов.Обмен на основе PDO-объектов используется для синхронной или асинхронной скоростной передачи не более 8 байт.

Он имеет более высокий приоритет,чем SDO и применяется для пересылок данных в режиме реального времени.Объекты специальных функций служат для выполнения ряда специальных задач:запуска синхронных процессов, передачи значения абсолютного времени и кодовошибок. Объекты сетевого управления включают сообщения NMT, LMT и DBTсервисов.Администрированием сети занимается NMT-мастер, который инициализирует устройства, обеспечивает контроль ошибок, а также производит их периодическую «перекличку» с помощью PDO-сообщений для выявления узлов, находящихся в нерабочем состоянии ввиду физического отсутствия или отключения отшины по счётчику ошибок.Для максимального упрощения процесса интеграции модулей независимыхпроизводителей в единую сеть в CANopen используется концепция профилей.Определён целый ряд профилей:• модули ввода/вывода (аналоговые и цифровые) (CiA Draft Standard DS401);• приводы и модули управления перемещением (CiA DS 402);• элементы человеко-машинного интерфейса (CiA DS 403);• измерительные устройства и регуляторы (CiA DS 404);• программируемые контроллеры, совместимые со стандартом МЭК 61131-3(CiA DS 405);• энкодеры (CiA DS 406);144• регулирующие клапаны, гидравлические механизмы (CiA DS 408);• уклономеры (CiA DS 410);• медицинские устройства (CiA DS 412);• ткацкие машины (CiA DS 414);• дорожные машины (CiA DS 415);• лифты (CiA DS 417);• поезда (CiA DS 421);а также другие профили, практически для всех отраслей, в которых могут применяться системы автоматического управления.Первым профилем приложения стал WD-407 (IBIS-CAN) для электронныхсистем управления на общественном транспорте Европы (билетный контроль,подсчёт пассажиров и т.

п.), где CAN-сети применяются достаточно широко.CAN Kingdom [54]Протокол шведской компании KVASER-AB [58] занимает особое место среди спецификаций протоколов верхнего уровня для CAN-сетей не только из-засвоего необычного названия (CAN Королевство), но и в значительной степениблагодаря оригинальной концепции сетевого взаимодействия и эффективностиCAN-приложений на его основе [55].