Материал: Протокол CAN-Kingdom

Протокол CAN-Kingdom

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение

Высшего профессионального образования

"Уфимский государственный нефтяной технический университет"

Кафедра автоматизации технологических процессов и производств

Курсовой проект

по дисциплине "Телеуправление и системы телекоммуникации"

на тему

Протокол CAN-Kingdom

Содержание

Введение

1. Область применения CAN-Kingdom

2. Спецификация CAN-Kingdom

3. Сравнительная характеристика HLP протоколов

Заключение

Список использованных источников

Введение

CAN протокол определяет безопасную передачу небольших пакетов данных из пункта А в пункт Б используя общую линию коммуникации. Протокол не содержит средств контроля потока, адресацию, не предоставляет передачу сообщений более чем 8 бит, не осуществляет установку соединения и т.д. Перечисленные свойства определяются HLP (Higher layer protocol) или Протокол Высшего Порядка.

Назначение HLP:

стандартизация процедур запуска и установка скорости передачи;

распределение адресации устройств и разновидности сообщений;

определение порядка сообщений;

обеспечивает механизм определения неисправностей системного уровня.

Условия HLP получены и состоят из семи порядков OSI модели. OSI модели (Open Systems Interconnect Model):;/CAL;;;;.обычно определяет:

параметры запуска;

распределение идентификатора сообщения среди различных устройств в системе;

интерпретация содержимого блоков данных;

статус взаимодействия в системе [1].

1. Область применения CAN-Kingdom

За довольно романтичным (CAN - королевство) названием протокола шведской компании KVASER-AB скрывается не менее красивая и оригинальная концепция сетевого взаимодействия устройств, выделяющая его на общем фоне других протоколов высокого уровня. Началу работ над первой версией (текущая - третья) протокола CAN-Kingdom в 1990 году предшествовал многолетний опыт компании в области создания систем распределенного управления.

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

CAN-Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике - от надувных лодок и систем наведения на цели до сверхзвуковых ракет и истребителей.

Основной целью создания протокола было предоставление системному разработчику максимальной свободы в реализации своих идей при построении сети, сохранив при этом возможность использования стандартных модулей независимых производителей. CAN-Kingdom не является "готовым" протокол в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее, набор примитивов - метапротокол, с помощью которых можно собрать "протокол" для конкретной сети модулей, что позволяет достичь уникального сочетания простоты интеграции готовых модулей с высокой степенью защищенности оригинального протокола [2].

2. Спецификация CAN-Kingdom

При разработке спецификации CAN-Kingdom авторы отказались от принятого в подобных случаях и широко распространенного следования правилам взаимосвязи открытых систем OSI. Причина этого проста: семиуровневая модель OSI/ISO (рисунок 1) создавалась изначально для описания традиционных компьютерных сетей, телекоммуникационных, корпоративных, офисных, которые предназначены не для работы в реальном масштабе времени, а для обслуживания пользователей, требования которых заранее (на этапе построения такой сети) неизвестны и непредсказуемы и в процессе работы подвержены частым изменениям (следует отметить, что большинство протоколов компьютерных сетей также редко в точности следуют этой абстрактной модели, особенно в плане обособления и полной изоляции различных уровней сетевого сервиса).

Рисунок 2.1 - CAN и модель OSI

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

На уровне канала данных протокол описывает два подуровня:

подуровень управления логической связью - Logical Link Control (LLC) - верхний подуровень;

подуровень управления доступом к среде - Medium Access Control (MAC).

Подуровень LLC предоставляет сервисы для передачи данных и удалённых запросов данных, решает, какие сообщения, полученные LLC подуровнем актуальны для данного узла.

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

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

Для передачи данных по физическому каналу используется кодирование без возвращения к нулю (NRZ-кодирование). Поскольку при NRZ-кодировании уровень сигнала может оставаться постоянным относительно долгое время, например, при передаче группы битов с одинаковыми значениями, то, чтобы избежать рассинхронизации приёмников и передатчика, после каждых пяти битов одинакового значения в сообщение вставляется один добавочный бит противоположного значения - правило добавочного бита. Естественно, приёмник удаляет все добавочные биты перед обработкой полученного сообщения.

По требованиям CAN-протокола, среда передачи должна находится в одном

из двух состояний: логический нуль (нижний уровень, CAN_L) - доминирующее состояние, а логическая единица (верхний уровень, CAN_H) - рецессивное состояние. При одновременной передаче доминирующего и рецессивного битов на шине должно присутствовать доминирующее значение. Этот механизм используется при арбитраже сообщений.

В CAN-протоколе используется метод широковещательной передачи сообщений - каждый приёмник сам решает, нужно ли ему обрабатывать очередное передаваемое сообщение. Содержание каждого сообщения определяется идентификатором сообщения. Идентификатор не определяет узел-приёмник, а описывает "смысл" передаваемых данных (можно сказать, что это имя передаваемой переменной), благодаря чему остальные узлы сети могут решить для себя, должны ли они обрабатывать передаваемые данные или нет.

Благодаря применению метода широковещательной передачи, CAN-устройства не используют никакой информации о конфигурации сети (адреса узлов отсутствуют). Узлы могут подключаться к сети и отключаться от неё без каких-либо изменений в настройках и программном обеспечении остальных узлов. Протокол также не ограничивает количество узлов, которые могут быть подключены к одной сети. На практике максимальное количество узлов сети определяется предельно допустимой нагрузкой на шину.

Когда шина свободна, любой узел может начать передачу. Если несколько узлов начали передачу одновременно, конфликт разрешается с помощью поля идентификатора сообщений (поля арбитража). Во время передачи сообщения, передатчик сравнивает значение передаваемого им бита со значением, установленным на шине. Если передаваемое и принимаемое значение бита совпадают, то узел может продолжать передачу. Если же при передаче рецессивного бита шина находится в доминирующем состоянии, то передатчик должен прекратить передачу (таблица 2.1). Таким образом, право на передачу по шине получает тот узел, который передаёт сообщение с наивысшим приоритетом. Важно понимать, что приоритетным является не передающий или принимающий узел, а сообщение [3].

Таблица 2.1 - Пример поразрядного арбитража

Краеугольным камнем концепции сетевого воздействия CAN-Kingdom является принцип "Модули обслуживают сеть" (MSN - Modules Serves the Network), в отличие от принципа "Сеть обслуживает пользователей" (NSM - Network Serves the Modules), свойственного компьютерным сетям.

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

Следствием принципа MSN также является и то, что в сети CAN-Kingdom всегда должен существовать один модуль - супервизор, содержащий всю информацию о системе и ответственный за ее инициализацию.

протокол линия коммуникация спецификация

Представление CAN-сети в терминах CAN-Kingdom (в сравнении с традиционным взглядом) дано на рисунке 2.2.

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

Рисунок 2.2 - Два взгляда на структуру CAN-сети: а) традиционный, б) с точки зрения протокола CAN-Kingdom

Для организации и хранения входящей и исходящей "корреспонденции" применяются понятия форм, документов, папок и листов. Типы почтовой корреспонденции (информация, передаваемая по сети) и ее соответствие CAN-понятиям показаны на рисунке 2.3.

Рисунок 2.3 - Типы почтовой корреспонденции

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

Перечислим некоторые особенности CAN-системы на базе протокола CAN-Kingdom.

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

2.      Максимальное время прохождения любого сообщения в сети предсказуемо.

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

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

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

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

.        Не существует каких-либо рекомендуемых скоростей передачи данных. Но в первые 200 мс после подачи питания узел обязан настроиться на прослушивание шины на скорости 125 Кбит/с. Допустимы отличающиеся от ISO 11898 спецификации физического уровня.

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

Среди возможностей CAN-Kingdom, способствующих повышению эффективности реализации режима реального времени, можно отметить гибкость режимов передачи и упаковки данных, включая использование поля арбитража для передачи данных, объединение узлов в группы, поддержку часов реального времени, различных режимов доступа к шине [4].

3. Сравнительная характеристика HLP протоколов

DeviceNet, SDS и CAN Kingdom основаны на ISO 11898 CAN коммуникационном протоколе и функционируют согласно требований CAN спецификации. Каждый CAN модуль, следующий определенному протоколу может быть подключен к CAN шине следующей тому же протоколу. В любом случае при подключении модулей, которые действуют по различными протоколам, в большинстве случаев проблемы возникают по причине конфликта интерпретации сообщений на уровне приложений. CAN Kingdom отличается от SDS и DeviceNet основным принципом: CAN Kingdom организуется главным узлом коммуникации ("King”) при запуске, в отличии от SDS и DeviceNet. Такая организация позволяет упростить разработку комплекса систем реального времени и сокращает необходимое количество модулей координирующих спецификации, часто обозначаемые как профили. SDS эффективен при подключении I/O устройств, различных выключателей и датчиков к PLC, фактически представляет собой соединение между основным модулем и удаленными I/O устройствами. DeviceNet открытая система, в которой все модули имеют равные права по пользованию шиной, и порядок пользования шиной определяется небольшим набором инструкций. Разработчик модулей системы может передать полномочия по управлению коммуникацией другим модулям, например основному модулю в предопределенном режиме главный/подчиненный, но DeviceNet не имеет возможности передать полномочия другим модулям. Характеристики SDS с использованием I/O устройств и DeviceNet в режиме главный/подчиненный сходны.Kingdom протокол, ориентированный на системы контроля и не поддерживает профили для цифровых и аналоговых устройств. Основная особенность протокола заключается в том что модуль, подключенный к системе только ожидает инструкции от главного устройства. Все CAN приоритеты и идентификаторы принадлежат и предоставляются главным устройством. Во время запуска каждый модуль конфигурируется основным устройством, определяются приоритеты и идентификаторы объектов продуцирующих и потребляющих. Основное устройство является главным, но только в период конфигурирования системы. Главное устройство не может быть внедрено в период коммуникационной сессии между работающими приложениями различных модулей. Основное устройство может быть удалено после конфигурирования и проверки комплектности, притом каждый модуль запоминает полученные инструкции в памяти.не требуется физическая адресация и номер узла. Это является важным свойством CAN, так как модули не должны иметь сведений о системе, в которой функционируют. Но во время конфигурирования системы и во время технического обслуживания сети, специфические узлы должны быть адресованы. Для этих целей, по крайней мере, один CAN приоритет/идентификатор должен быть зарезервирован и каждому модулю присвоен номер узла. CAN Kingdom, DeviceNet и SDS используют подобную технологию.