Размещено на http://www.allbest.ru

Оглавление

• Введение 3
• 1. Общие сведения 4
• 2. Основные характеристики сети 4
• 3. Описание протокола CAN 5
• 3.1 Физический уровень протокола CAN 5
• 3.1.1 Рецессивные и доминантные биты 5
• 3.1.2 Функциональная схема сети стандарта CAN 6
• 3.1.3 Скорость передачи и длина сети 7
• 3.2 Канальный уровень протокола CAN 8
• 3.2.1 Кадры 8
• 3.2.2 Арбитраж доступа 10
• 3.2.3 Методы обнаружения ошибок 10
• 4. Протоколы высокого уровня 11
• 5. Применение CAN 12
• Заключение 13
• Список использованной литературы 14

• Введение
• Промышленная сеть -- сеть передачи данных, связывающая между собой контроллеры и различные датчики, исполнительные механизмы.
• Задача промышленных сетей -- организация физической и логической связи различных компонентов автоматизации таким образом, чтобы информация с этого уровня была доступна общезаводской информационной системе.
• Изначально промышленные сети создавались для того, чтобы уменьшить потребность в прокладке отдельных кабелей от каждого устройства к плате ввода/вывода контроллера. Возьмем самую простую сеть, которая будет объединять группу отдельных приборов и контроллер для обеспечения управления одним технологическим процессом или одним станком. Эти устройства можно жестко подключить к платам ввода/вывода, не пользуясь сетью вообще. Однако, если количество приборов увеличивается во много раз или возрастет расстояния между ними, такой путь решения проблем становится дорогим и громоздким. Самая простая сеть объединяет эти приборы вместе, снижая тем самым количество проводов и облегчая процедуру конфигурирования контроллера (задание системных настроек, определение соответствия физических входов/выходов списку оборудования, программирование дополнительных функций и т.д.).
• Сформулируем некоторые основные требования, которые можно предъявить к идеальной промышленной сети:

· жесткая детерминированность (предсказуемость) поведения;

· обеспечение функций реального времени;

· повышенная надежность физического и канального уровней передачи данных, помехоустойчивость;

· возможность дуплексной передачи;

· работа на длинных линиях с использованием недорогих физических сред (например, витая пара);

· максимальный сервис для приложений верхнего уровня;

· минимальная стоимость устройств аппаратной реализации, особенно на уровне контроллеров;

· управляемость и самовосстановление в случае возникновения нештатных ситуаций;

· открытость.

В зависимости от области применения весь спектр промышленных сетей можно разделить на два уровня:

sensor/actuator level (уровень датчиков) - задачи сетей этого уровня сводятся к опросу датчиков и управлению работой разнообразных исполнительных механизмов. Здесь основным параметром является время и частота опроса каналов датчиков. Типичные представители этого уровня Profibus-DP/PA, Interbus-S.

field level (системный уровень) - промышленные сети этого уровня решают задачи по управлению процессом производства, сбором и обработкой данных на уровне промышленных контроллеров. На этом уровне на первый план выдвигается задача передачи больших объемов данных, при этом схема потоков данных может быть достаточно сложной. Типичные представители этого уровня Profibus-FMS, Bitbus.

Отметим, что существуют сети для обоих уровней применения, типичными представителями которых являются рассматриваемая в этом реферате сеть CAN, а также FIP и др.



1. Общие сведения

Шина CAN (Controller Area Network) разрабатывалась фирмой BOSCH начиная с 1982 года. Первая презентация этой шины была проведена в 1986 г. в Детройте на конференции сообщества инженеров автомобилестроения (SAE), что, разумеется, не случайно, ведь шина CAN изначально разрабатывалась для применения в автомобильной электронике для построения распределенных систем контроля и управления как основными агрегатами, так и вспомогательными. В настоящее время сеть CAN активно применяется за пределами автомобильной промышленности - в промышленной автоматизации, в технологиях «умного дома» и прочих областях.

Мировое признание сетей CAN закреплено в международном стандарте ISO 11898. Стандарт определяет протоколы физического уровня и двух подуровней канального доступа к среде передачи и управления информационным каналом.



2. Основные характеристики сети

Сеть CAN основана на шинной топологии с децентрализованным доступом на основе протокола CSMA/CD+AMP (Carrier Sense Multiple Access With Collision Detection and Arbitration on Message Priority). Этот протокол описывает алгоритм арбитража по приоритету сообщения на основе множественного доступа с обнаружением несущей и детектированием коллизий. Коллизии разрешаются с помощью процедуры арбитража на основе состязания, при которой попытка захвата шины осуществляется многими узлами одновременно и для получения доступа проводится их состязание. По своим характеристикам интерфейс удовлетворяет не только требованиям задач реального времени, но и реализует высокую степень обнаружения и исправления ошибочных телеграмм. 

 Основные характеристики:

· Детерминированность; (Регламентация доступа к среде передачи)

· Распределенная проводная сеть связи с неограниченным количеством равнодоступных узлов;

· Оперативное изменение числа узлов сети без изменения конфигурации остальных узлов;

(При удалении неисправного оборудования одного или нескольких узлов полностью сохраняется работоспособность оставшейся сети без изменения программных или аппаратурных установок.)

· Широковещательная передача данных в сети;

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

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

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

· Система приоритетов передаваемых сообщений;

(Позволяет регулировать срочность распространения сообщений в сети - внеочередная передача сигналов аварии или безопасности.)

· Внутренняя диагностика исправности трансиверов и контроллеров, автоматическое отключение неисправного оборудования.

(Обеспечивает неискажение информации в сети дефектными устройствами и исключает возможность посылки сообщений дефектным устройствам.)



3. Описание протокола CAN

Протокол CAN описывает два нижних уровня эталонной сетевой модели ISO/OSI (Рис. 1):

· канальный уровень (Data Link Layer);

· физический уровень (Physical Layer).

Остальные уровни описываются протоколами HLP (Higher Level Protocol).

Рис. 1 Модель ISO/OSI

3.1 Физический уровень протокола CAN

Физический уровень не полностью определен в спецификации CAN. Спецификация описывает подуровень физической сигнализации (Physical Signaling - PLS physical signaling (PLS) - принимает и передает в схему трансивера битовый поток. ), оставляя за разработчиком право выбрать любой драйвер/приёмник и среду передачи (дифференциальная пара, радиоканал, оптоволокно и пр.), если они соответствуют требованиям PS-подуровня. протокол сеть доминантный бит

Существует несколько физических уровней протокола CAN, определенных в различных стандартах (ISO 11898, ISO 11519, SAE J2411). В подавляющем большинстве случаев используется физический уровень CAN, определенный в стандарте ISO 11898. Его мы рассмотрим подробнее.

ISO11898 - международный стандарт для высокоскоростной связи CAN, применяемой в транспортных средствах. В качестве среды передачи он определяет двухпроводную дифференциальную линию с импедансом 120 Ом (Рис. 2).

В высокоскоростных CAN сетях с линейной топологией для подавления отражений сигнала к обоим концам шины подсоединяются резисторы-терминаторы.

3.1.1 Рецессивные и доминантные биты

Для абстрагирования от среды передачи спецификация CAN избегает описывать двоичные значения как «0» и «1». Вместо этого, CAN определяет два логических состояния: рецессивное (recessive) и доминантное (dominant). Например, при реализации физического уровня на радиоканале отсутствие сигнала означает рецессивный бит, а наличие -- доминантный, тогда как в типичной реализации проводной сети рецессив бывает при наличии сигнала, а доминант, соответственно, при отсутствии. Стандарт сети требует от «физического уровня» фактически единственного условия: чтобы доминантный бит мог подавить рецессивный, но не наоборот. Логическое значение доминантного бита - `0'. Логическое значение рецессивного бита - `1'.

Рис. 2 Дифференциальная шина

3.1.2 Функциональная схема сети стандарта CAN

Типовая функциональная схема сети стандарта CAN включает шину, приемопередатчики и котроллеры (Рис. 3).



Рис. 3 Шина CAN

Приемопередатчик CAN

Приемопередатчик (трансивер) предназначен для сопряжения CAN контроллера и физической шины. Он обеспечивает прием и передачу сигнала в линию.

· прием данных осуществляется через приемный тракт. Он содержит компаратор компаратор шины (bus comparator) - Элемент, который осуществляет преобразование физических сигналов, распространяемых в коммуникационной среде, в логическую информацию или данные., обеспечивающий распознавание доминантного и рецессивного состояний CAN-шины, и формирователь цифрового сигнала;

· передача данных происходит через передающий тракт, содержащий таймер, схему задания крутизны сигнала, узел управления передатчиком (драйвер драйвер шины (bus driver) - Элемент, который осуществляет преобразование логической информации или данных в физические сигналы, которые могут передаваться в коммуникационной среде.), выходную схему на полевых транзисторах и схему температурной защиты;

· таймер предназначен для ограничения продолжительности доминантного состояния, защищая CAN-шину от возможных сбоев CAN-контроллера;

· формирователь фронтов ограничивает скорость их нарастания, снижая электромагнитное излучение, и позволяет отказаться от внешних синфазных дросселей;

· узел управления передатчиком осуществляет управление двумя полевыми транзисторами, формирующими состояние на линиях CAN-H и CAN-L. В доминантном состоянии оба транзистора открыты, обеспечивая на линии CAN-H высокий, а на линии CAN-L - низкий уровень;

· схема температурной защиты предохраняет микросхему от выхода из строя, отключая передатчик, если температура превышает значения порядка 160°C. 

Контроллер CAN

Контроллер обеспечивает взаимодействие с сетью. Он осуществляет инкапсуляцию/декапсуляцию данных, битовое хронирование Битовое хронирование (bit timing) - установка регистров битового хронирования CAN контроллера. Определяется квантом времени, который зависит от частоты опорного генератора и параметров делителя битовой скорости узла., подсчет CRC, бит стафинг Бит стафинг (bit stuffing) - вставка дополнительных бит в поток данных для обеспечения смены уровня сигнала на шине и возможности периодической ресинхронизации., обработку ошибок, локализацию отказов, ресинхронизацию Битовая ресинхронизация (bit resynchronization) - Ограниченная точность опорных генераторов, может привести к выходу из синхронизации какого-либо узла. CAN контроллер осуществляет ресинхронизацию по каждому переходу сигнала с рецессивного на доминантный уровень. и др.

Включает в себя:

· память для принимаемых и передаваемых сообщений;

· формирователь сигналов прерывания для микроконтроллера (MCU);

· маски и фильтры для определенного типа сообщений или приоритетов;

· АЦП, ЦАП и сигналы ШИМ для связи с датчиками и индикаторами.

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

3.1.3 Скорость передачи и длина сети

Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице 1.

Таблица 1

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

Количество узлов в сети CAN теоретически не ограничено. Практически же максимальное количество ограничивается на уровне 127.



3.2 Канальный уровень протокола CAN

Канальный уровень полностью определяется спецификацией CAN. Он делится на 2 подуровня -- MAC (Media Access Control) и LLC (Logical Link Control).

Подуровень управления логической связью (LLC) описывает верхние компоненты канального уровня ISO/OSI. Он касается тех аспектов протокола, которые не зависят от метода доступа к коммуникационной среде, в частности обеспечивает управление перегрузкой и уведомление о ней, а также фильтрацию сообщений и функции управления восстановлением.

Подуровень управления контролем доступа к среде (MAC), представляет нижние компоненты канального уровня ISO/OSI. MAC включает в себя правила и функции, относящиеся к инкапсуляции/декапсуляции, обнаружению ошибок и выдаче сигналов.

3.2.1 Кадры

Передача данных в CAN сети ведётся кадрами. Кадр (frame) - тип данных канального уровня, определяющий порядок и значение бит или битовых полей в передаваемой последовательности. Стандарт CAN различает основной формат кадра, использующий 11 битовые идентификаторы, и расширенный формат с 29 битовыми идентификаторами.

В CAN используются четыре типа кадров:

1. Кадр данных (data frame): 

Наиболее часто используемый тип сообщения. Он состоит из следующих основных частей (рис. 4):



Рис. 4 Кадр данных стандарта CAN 2.0A

Поле SOF (start of frame) - это самый первый бит каждого кадра данных и кадра удаленного запроса. Состояние SOF всегда доминантное. Если шина свободна, то любой узел сети может начинать передачу кадра. В сети CAN доступ к шине инициируется передачей именно доминантного SOF бита.

Поле арбитража (arbitration field) - используется в CAN для разрешения коллизий доступа к шине. Оно состоит из 11-битного идентификатора и поля RTR:

o идентификатор (Identifier field) - определяет важность содержимого кадра данных. Он неявно задает приоритет арбитража сообщения в случае, когда два или более узлов одновременно пытаются передать данные в сеть;

o поле RTR (remote transmit request) - указывает, является ли данный кадр кадром удаленного запроса (рецессивный уровень) или кадром данных (доминантный уровень).

Флаг расширенного идентификатора (Identifier Extension Flag) - указывает, каким образом нужно интерпретировать последующие биты: как контрольные, или как задающие вторую часть 29-ти битового идентификатора.

Контрольное поле (control field) - содержит информацию о кадре и состоит из:

o 2-х зарезервированных бит, находящихся всегда в доминантном состоянии;

o поля DLC (Data Length Code), которое содержит длину поля данных кадра. DLC указывается 4-х битовым кодом.

Поле данных (data field) - содержит от 0 до 8 байт полезных данных. Длина поля указывается кодом DLC.

Поле CRC (Cyclic Redundancy Check) - содержит 15-битную контрольную сумму сообщения и битовый разграничитель (всегда рецессив). Используется для обнаружения ошибок. Рассчитав CRC для блока принятых данных и сравнив его со значением, полученным от передающей стороны, принимающая сторона может определить некоторые типы ошибок. Проверка циклического избыточного кода выполняется на основе полинома, рассчитываемого как в передающем, так и в принимающем узлах.

Поле подтверждения ACK (acknowledge field) - состоит из двух бит: слота подтверждения и разделителя подтверждения.

o cлот подтверждения (Acknowledgement Slot) - первый бит поля подтверждения ACK. Устанавливается рецессивным со стороны передающего узла и доминантным со стороны всех получателей, которые осуществили успешную проверку CRC (циклического избыточного кода). Если передающий узел обнаруживает доминантное состояние этого бита, он может быть уверен, что хотя бы один узел принял сообщение без ошибок;

o разделитель подтверждения (acknowledge delimiter) - второй бит поля подтверждения CAN кадра. Является рецессивным. Доминантное значение разделителя считается нарушением формата и вызывает передачу кадра ошибки.

Конец кадра (End Of Frame) - состоит из семи рецессивных бит.

2. Кадр удаленного запроса (remote frame): 

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

3. Кадр перегрузки (overload frame): 

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

4. Кадр ошибки (error frame): 

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

Все CAN кадры, в том числе кадры ошибки и перегрузки, отделяются от предыдущих кадров межкадровым промежутком. Он формируется тремя рецессивными битами.

3.2.2 Арбитраж доступа

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

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

Таким образом, в отличие, например, от Ethernet, в CAN не происходит непроизводительной потери пропускной способности канала при коллизиях. Цена этого решения -- вероятность того, что сообщения с низким приоритетом никогда не будут переданы.

Рис. 5 Побитовый арбитраж на шине CAN

3.2.3 Методы обнаружения ошибок

CAN протокол определяет пять способов обнаружения ошибок в сети:

· Bit monitoring;

· Bit stuffing;

· Frame check;

· ACKnowledgement Check;

· CRC Check.

Bit monitoring - каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита, которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку Bit Error. Естественно, что во время арбитража на шине (передача поля арбитража в шину) этот механизм проверки ошибок отключается.

Bit stuffing - когда узел передает последовательно в шину 5 бит с одинаковым значением, то он добавляет шестой бит с противоположным значением. Принимающие узлы этот дополнительный бит удаляют. Если узел обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку Stuff Error.

Frame Check - некоторые части CAN-сообщения имеют одинаковое значение во всех типах сообщений. Это означает, что протокол CAN точно определяет, какие уровни напряжения и когда должны появляться на шине. Если формат сообщений нарушается, то узлы генерируют ошибку Form Error.

ACKnowledgement Check - каждый узел, получив правильное сообщение по сети, посылает в сеть доминантный бит. Если же этого не происходит, то передающий узел регистрирует ошибку Acknowledgement Error.

CRC Check - каждое сообщение CAN содержит CRC сумму, и каждый принимающий узел подсчитывает значение CRC для каждого полученного сообщения. Если подсчитанное значение CRC суммы не совпадает со значением CRC в теле сообщения, принимающий узел генерирует ошибку CRC Error.

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



4. Протоколы высокого уровня

Базовая спецификация CAN лишена многих возможностей, требуемых в реальных системах: передача данных длиннее 8 байт, автоматическое распределения идентификаторов между узлами, единообразное управление устройствами различных типов и производителей и пр. Все эти возможности являются предметом рассмотрения протоколов высокого уровня (HLP - Higher Layer Protocols). Название HLP отражает тот факт, что протокол CAN описывает только два нижних уровня эталонной сетевой модели ISO/OSI, а остальные уровни описываются протоколами HLP.

Существует большое число разработок протоколов высокого уровня для CAN, оформленных как самостоятельные протокольные решения. Ниже приведены лишь некоторые, наиболее известные, из них:

· SDS (Smart Distributed System) (Honeywell);

· DeviceNET (Allen Bradley);

· CAL\CANopen (CiA-ассоциация CiA (CAN in Automation) - является международным сообществом пользователей и производителей решений на основе CAN. Поддерживает ряд протоколов высокого уровня. Осуществляет официальную сертификацию CANopen устройств. Основано в 1992 году.);

· Kingdom (Kvaser).

SDS -- детище компании Honeywell Inc. Представляет собой недорогое и законченное решение для сетевого управления интеллектуальными датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации. По степени завершенности -- от спецификаций физической среды до прикладного уровня. Архитектура протокола SDS включает в себя три уровня модели OSI/ISO -- физический, канальный и прикладной. Шинная топология представляет собой линейную шину с короткими отводами.

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

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

CAN Kingdom - Структура высокоуровневого протокола, оптимизированная для глубоко встроенных сетей. Протокол был специально разработан для управления движущимися машинами и механизмами. Он позволяет достичь высокой производительности в режиме реального времени при удовлетворении жестких требований безопасности. CAN Kingdom является также основой американского военного стандарта CDA 101 и широко используется в военной технике - от надувных лодок и систем наведения на цели до сверхзвуковых истребителей и ракет. CAN Kingdom не является “готовым” протоколом в том смысле, в каком это справедливо, например, по отношению к стандартам типа CANopen или DeviceNet. Это скорее набор примитивов, с помощью которых можно “собрать” протокол под конкретную сеть модулей. Этим достигается уникальное сочетание простоты интеграции готовых модулей с высокой степенью “закрытости” оригинального протокола.

Лидерами в этом семействе, являются SDS и DeviceNET (американский рынок) и CAL (Европа).



5. Применение CAN

Такие отличительные характеристики CAN как: широковещательный способ передачи, превосходная обработка ошибок, различная среда передачи, наличие аппаратной поддержки - обусловили лавинное увеличение приложений на базе CAN и расширение областей применения:

В предыдущем пункте уже приводились кратко возможные применения сети CAN. В этом пункте, в качестве более конкретных примеров применения шины CAN, будут приведены некоторые существующие профили устройств, разработанные членами CiA:

· CiA 408 - профиль CANopen устройства для гидравлических контроллеров и пропорциональных клапанов. Совместим с независимым от сети VDMA профилем;

· CiA 410 - профиль CANopen устройства для уклонометров. Поддерживает как 16-и, так и 32-х разрядные датчики;

· CiA 412 - профили CANopen устройств для медицинского оборудования. Определяют интерфейсы рентгеновских коллиматоров, генераторов рентгеновского излучения, медицинских стоек и столов;

· CiA 414 - профиль CANopen устройства для ткацких машин. Определяет интерфейс подающего механизма;

· CiA 415 - прикладной профиль CANopen для асфальтоукладчиков. Определяет интерфейсы различных устройств, используемых в дорожно-строительной технике;

· CiA 416 - прикладной профиль CANopen для дверей зданий. Определяет интерфейсы замков, сенсоров и других устройств, используемых в управляемых электроникой дверях;

· CiA 417 - прикладной профиль CANopen для лифтов. Определяет интерфейсы контроллеров кабины, дверей, контроллера вызова и других, а также узлов кабины и дверей, кнопочных панелей и др;

· CiA 418 - профиль CANopen устройства для батарейных модулей. Определяет интерфейс для работы с зарядными устройствами;

· CiA 419 - профиль CANopen устройства для зарядных устройств. Определяет интерфейс для работы с батарейными модулями;

· CiA 420 - семейство профилей CANopen устройства для экструдеров. Определяет интерфейсы для вытягивателя, гофрирователя и распиловщика;

· CiA 422 - прикладной профиль CANopen для муниципальных транспортных средств. Используется, в частности, для управления дополнительным оборудованием мусороуборочных машин и определяет интерфейсы таких подсистем, как прессовщик, весы и др.;

· CiA 425 - CANopen профиль для вспомогательных медицинских устройств. Определяет plug-and-play интерфейсы инжектора контрастного вещества и электрокардиографа.



Заключение

Протокол CAN оптимизирован для систем, в которых должно передаваться относительно небольшое количество информации (по сравнению с USB или Ethernet) к любому или всем узлам сети. Он обладает большим количеством преимуществ, среди которых:

· Множественный доступ с опросом состояния шины позволяет каждому узлу получить доступ к шине с учетом приоритетов.

· Неадресатная структура сообщений позволяет организовать многоабонентскую доставку данных с сокращением трафика шины.

· Быстрая устойчивая передача информации с системой контроля ошибок позволяет отключать неисправные узлы от шины, что гарантирует доставку критических по времени сообщений.

С учетом того, что на рынке предложен большой ассортимент узлов ввода/вывода, датчиков и приводов для прикладных протоколов CANopen и DeviceNet, можно утверждать, что CAN незаменим для новых разработок, в которых важную роль играют такие параметры как реальное время, стабильность связи, отказобезопасность, доступность надежных стеков и инструментальных средств для прикладных протоколов.

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



Список использованной литературы

1. Древс Ю.Г., Зорин А.Л. Применение ПЭВМ в системах измерения и обработки данных. Часть 2. Технические средства сбора информации в измерительно-вычислительных комплексах: Учебное пособие. М.: МИФИ.

2. Карпенко 3.Е. Возможности CAN-протокола // Современные технологии автоматизации. - 1998 №4, с.16-20.

3. Любашин А.Н. Промышленные сети // Мир компьютерной автоматизации. - 1999. №1

4. Третьяков С.А. CAN на пороге нового столетия // Мир компьютерной автоматизации. - 1999. №2

5. Щербаков А. Протоколы прикладного уровня CAN-сетей // Современные Технологии Автоматизации. - 1999. №3

6. Robert Bosch GmbH «CAN Specification Version 2.0», 1991.

7. Зитцманн Рейнер, Мак Моника, Цельтвангер Хольгер, Шуманн Тило. CAN словарь. Второе издание. Пер. с англ. Грибов Игорь, 2005

8. IXXAT Automation GmbH. CAN vs. RS-485: Пер. с англ. ООО НПКФ «ДЭЙТАМИКРО», 2012

9. Pat Richards. AN228 - A CAN Physical Layer Discussion: Пер. с англ. PIClist, 2007

10. ООО «Марафон». Введение в протокол CAN. - URL: http://can.marathon.ru/page/can-protocols/canbus/canintro

11. ООО «СМД Комп». Протокол CAN - оптимальное построение бортовой сети автомобиля. - URL: http://www.smd-component.ru/pdf/can-basic.pdf

12. Dmitry. Протокол CanOpen. URL: http://robot-develop.org/archives/4110

13. Протоколы прикладного уровня CAN-сетей: SDS (Smart Distributed System). URL: http://www.aldis.ru/techno/nets/can-protocols/sds/

14. Щербаков А. Сеть CAN: популярные прикладные протоколы. URL: http://catalog.gaw.ru/index.php?page=document&id=1428

Размещено на Allbest.ru