Протокол 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 используют подобную технологию.

Некоторые способы присвоения номера узла.

.        DIP переключатель.

Свойства: Повышенная возможность возникновения ошибок допущенных человеком, и ошибок по причине неисправностей соединения. Обычно отсутствуют

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

Рекомендации: Номер узла должен быть доступен без применения, какого либо сервисного инструмента.

.        Кодирование контактами разъема.

Свойства: Повышенная возможность возникновения ошибок допущенных человеком, и ошибок по причине неисправностей соединения. Обычно отсутствуют

ошибки, которые возможно проверить чексуммой. Установки разъема могут быть доступны или в открытом состоянии, либо посредством смотрового окна в корпусе. Требует документации по изменению установок разъема. Ограниченное количество комбинаций. Высокая стоимость контактов разъема.

Рекомендации: Номер узла должен быть доступен без применения, какого либо сервисного инструмента.

.        Хранение во внутренней памяти.

Свойства: Номер узла должен быть установлен в модуль до подключения к системе.

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

.        Хранение номера в памяти разъема.

Свойства: Отсутствие в продаже разъемов со встроенной памятью. Потребуются дополнительные контакты для считывания информации из памяти.

Рекомендации: Тоже, что для внутренней памяти. Если номер узла сохраняется и в памяти разъема и в энергонезависимой внутренней памяти, достигается высокий уровень защиты от замены и перемещения модулей. Не требуется применение сервисных инструментов. Ни в одном из HLP протоколов не специфицирован метод установки номера узла. SDS и DeviceNet описывают применение переключателей с применением каких либо разновидностей инструментов.

В CAN сети важно чтобы все модули были установлены для обмена данными на одной скорости. Следующим, после короткого замыкания CAN шины, наипростейшим способом разрушить коммуникации является установка модуля с некорректной или очень низкой скоростью обмена данными. Обычные последствия заключаются в том, что остальные модули отключаются. CAN Kingdom и DeviceNet рекомендуют различные способы, чтобы избежать подобные последствия.описывает рекомендованную методику автоматической настройки скорости обмена данными. Скорость обмена устанавливается главным устройством, которому присвоен наименьший адрес. Другие модули проверяют своевременность обмена по шине и устанавливают собственную скорость соответственно. Рекомендованные значения 125к, 250к, 500к и 1 М.определяет три значения скорости 125к, 250к и 500к, но не обеспечивает защиту от сбоев установки скорости обмена данными. Если не определено, некоторые DeviceNet устройства используют автоматическую настройку скорости.Kingdom не определяет скорость обмена или автоматическую настройку. Модуль после включения питания в течение первых 200 ms должен "слушать" пассив на скорости 125 kbit с фиксированными и определенными установками. Во время этой процедуры неправильно настроенный модуль может быть всегда доступен при таких условиях. Пассивная коммуникация означает, что модуль только "слушает" CAN сеть, но не предоставляется возможность передачи доминантных битов по шине.

Приоритет доступа к CAN шине дается первыми 11 или 29 битами сообщения, и называется "Поле идентификатора" или более корректное название "Поле приоритета".11 бит ID называется Standard ID и 29 бит Extended ID. SDS и DeviceNet используют Std. IDs. CAN Kingdom использует и Std и Ext. IDs. SDS позволяет подключение 125 модулей к сети, и каждому модулю присваивается набор IDs относительно каждого номера узла.и DeviceNet определяют профили, для большого количества различных устройств, включая поведение и структуру данных принимающих и передающих модулей. Необходимо что бы модуль, не принадлежащий системе, соответствовал протоколу системы.

В CAN Kingdom всегда присутствует модуль, который отвечает за систему, по крайней мере, при запуске системы первый раз. Определяется возможности модуля приспосабливаться к конкретным условиям, т.е. профилированием системных данных, таких как скорость обмена, номер узла и приоритеты. В таблицах 3.1 - 3.4 приведены некоторые характеристики трех HLP [5].

Таблица 3.1 - Скорость передачи данных

Таблица 3.2 - Количество узлов

Таблица 3.3 - Базовые данные приоритетов и идентификаторов

Таблица 3.4 - Управление системой

Заключение

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

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

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

1.      Программа Н4 повышения квалификации специалистов, учреждений и предприятий г. Москвы на основе новейших достижений в науке и технологиях / ФГОУ ВПО МГАУ // Часть 2 "Современные методы управления машинами с использованием шины Controller Area Network". - 2011. - 55 с.

2.      Щербина, Ю.В. Технические средства автоматизации и управления: Учеб. пособ. / Ю.В. Щербина. - М.: МГУП, 2002. - 448 с.

.        Аппаратные средства и программное обеспечение систем промышленной автоматизации: Учеб. пособ. / И.А. Данилушкин. - Самара.: Самар. гос. техн. ун-т., 2005. - 168 с.

.        Протоколы прикладного уровня CAN-сетей / Журнал "Современные технологии автоматизации" // [Электронный ресурс]: - 1996-2014. - URL: http://www.cta.ru/rubrics/239890_239961_239913. htm (дата обращения 21.12.2014).

5.      CAN / Украинский автоцентр // [Электронный ресурс]: - 2009 - 2014. - URL: http://auto-profi.com.ua/page. php? idpages=809 (дата обращения 21.12.2014).