Просмотр исходного текста страницы CANopen

{{-}}'''CANopen''' — открытый сетевой протокол верхнего уровня для подключения [[Встраиваемая система|встраиваемых устройств]] в бортовых транспортных и [[полевая шина|промышленных сетях]]. В качестве сетевого и транспортного уровня использует протокол [[Реальное время|реального времени]] [[Controller Area Network|CAN]]. Используется для связи датчиков, исполнительных механизмов и [[Программируемый логический контроллер|программируемых логических контроллеров]] между собой. Открытый стандарт.

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

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

== Недостатки ==
Малая распространённость за пределами Европы.

== Перспективы ==
Помимо протокола прикладного уровня, CANopen означает членство в клубе разработчиков аппаратуры "по интересам". Подробнее можно узнать на сайте CiA(www.can-cia.org). Вступить в данную организацию могут все, кто посчитает это нужным. Организация объединяет в том числе и ведущих производителей автомобилей в Европе.

== Структура стандартов ==
Структура организации перекликается со структурой стандартов регламентирующих работу CANopen сетей.

В основе протокола прикладного уровня лежит документ DS.301, который в свою очередь является практическим развитием идей декларированных в документах CiA DS-201-207. Он определяет протоколы конфигурирования и функционирования сети.

CANopen сеть ориентирована на применение микроконтроллеров, в том числе и самых дешёвых, поэтому разбивается на ряд необязательных подсистем, что позволяет использовать только лишь необходимые функции.

Функционирование сети — это обмен данными. Для понимания функционирования сети CANopen разделим все данные на функциональные и технологические.

Функциональные данные — те данные, которые описывают целевое функционирование системы (температура, величины управляющих воздействий исполнительных механизмов), те данные, которые передавались бы между блоками, даже если бы в качестве связующего звена использовалась линия связи отличная от [[Can|CAN]], например, [[LIN]] или [[USB]], или [[Ethernet]], или [[I²C|I2C]].

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

Документ CiA DS-201 выделяет 4 основных группы подсистем (Fig.3 CiA DS-201)
 CMS — передача сообщений. Сюда относятся: обмен функциональными данными, обмен срочными сообщениями, обмен данными по запросу,   
 управление объектным словарём
 NMT — управление сетью, контроль работы устройств сети
 DBT — динамическое распределение идентификаторов
 LMT — управление конфигурированием устройства

* 1. Обмен функциональными данными в реальном времени '''''ключевое слово PDO, CMS ''''' (основная подсистема, в принципе необязательная, но если не будет ни одной из остальных подсистем то данное пустое множество может называться CANopen лишь потенциально).
  ПРИМЕР  Система поддержания температуры в помещении основной блок, измерители температуры, нагреватели/испарители 
* Словарь объектов — это не подсистема '''''ключевое слово PDO, SDO, entry, Index'''''. Словарь используется всеми подсистемами и описывает целевые данные которыми надлежит обмениваться, правила обмена. Можно провести параллель с реестром в Windows.
  ПРИМЕР  Температура в отдельных точках и параметр управления нагревателями/испарителями
* 2. Синхронизация обмена данными '''''ключевое слово SYNC''''' (необязательная, но такая же целесообразная подсистема, как и подсистема 1). При использовании данной подсистемы в сети существует генератор синхросообщений, периодически передающий высокоприоритетное сообщение SYNC. После появления в сети такого сообщения все синхронизируемые устройства производят обмен данными в течение заданного временного интервала(окно синхронного обмена данными). Коллизии(одновременная передача данных двумя и более устройствами) разрешаются на уровне физического уровня протокола CAN. Словарь объектов содержит перекрёстные ссылки откуда какие данные взять, и какие куда положить. Таким образом приложения не занимаются самостоятельно сбором данных, просто в определённых переменных (с точки зрения приложения) периодически оказываются свежие данные. Аналогично с управляющими воздействиями. При этом режиме обмен может происходить не только между датчиками и основным блоком, но и между датчиками минуя основной блок.
* Асинхронный обмен данными. Включает обмен сообщениями сетевого управления (управления узлами сети) '''''Network Management, NMT Services''''', сообщениями подсистемы контроля работы сети (вариант Обнаружения ошибок работы сети) '''''Error Control''''', срочными сообщениями — авральными объектами (обнаружение ошибок работы узлов) '''''Emergency Object, EMCY'''''. Сообщения данного класса могут появиться в любой момент времени, в том числе и внутри окна синхронного обмена данными. Данные сообщения имеют высокий приоритет (выше, чем сообщений, составляющих пакеты данных), а коллизии разрешаются на уровне физического уровня протокола CAN. Для реализации данных подсистем в сети назначается (на этапе проектирования сети) устройство ответственное за работу конкретной подсистемы. Помимо этого имеются механизмы динамического назначения подобных устройств. Теперь подробно.
** 3. Управление узлами сети '''''Network Management, NMT Services''''' (необязательная подсистема). Сеть может быть спроектирована таким образом что после включения каждый прибор, завершив инициализацию, перейдёт в состояние готовности, но при этом не будет участвовать в обмене функциональными данными до тех пор, пока мастер управления работой сети (NMT master) не разрешит его работу. В состоянии готовности устройство не принимает участие в обмене функциональными данными но может обмениваться технологическими данными. В состоянии готовности устройство может быть сконфигурировано(см далее Подсистема управления словарём объектов). При помощи данной подсистемы мастер сети может выполнить сброс и перезапуск любого из узлов, для которого потребуется такая процедура. Мастер получает от прибора сообщения, в которых указано реальное состояние прибора, если реальное состояние не соответствует ожидаемому, то это расценивается как ошибка. Реакции на ошибки рассмотрены ниже по тексту.
**4. Контроль работы сети (обнаружение ошибок работы сети) '''''NMT Error Control Protocols, Node Guarding, Heartbeat Protocol''''' (необязательная подсистема). Некоторые системы (особенно связанные с безопасностью) должны контролировать наличие и исправность всех штатных датчиков.
  ПРИМЕР Датчик-концевик при срабатывании которого должен сразу отключаться двигатель. 
  Если сам датчик стал вдруг неисправен, то при замыкании концевика он не передаст сообщение 
  об этом основному блоку, что чревато аварийной ситуацией, поэтому при обнаружении неисправности 
  такого датчика необходимо сразу отключать двигатель
Обнаружение ошибок работы сети ('''''Node Monitoring''''') производится двумя сходными способами<ref>[http://www.canopensolutions.com/english/about_canopen/guarding_heartbeat.shtml CANopen Basics - Guarding and Heartbeat]</ref>
*** I. Перекличка узлов '''''Node Guarding'''''. Мастер периодически опрашивает узлы, которые отвечают. Как только узел перестаёт отвечать, отмечается ошибка для этого датчика, и мастер в соответствии с логикой работы может остановить потенциально опасные процессы. Узел, который не будет опрошен в течение определённого времени (оборвалась линия), также отмечает для себя ошибку. Недостатки этого способа - запросы от мастера отнимают часть пропускной способности сети и отказ единственного узла (мастера) приводит к отказу всей сети.
*** II. Контрольное тактирование. '''''Heartbeat''''' (''букв. англ. "сердцебиение"''). Все узлы сети самостоятельно, без запроса, регулярно передают сообщения о своём состоянии - "heartbeat message". Если в течение контрольного интервала сообщения от какого-то узла отсутствуют, другие узлы, подписанные на его сообщения, отмечают для себя ошибку. Этот способ лишён недостатков предыдущего и рекомендован к применению в современных системах<ref>''Olaf Pfeiffer, Andrew Ayre, Christian Keydel'' Embedded Networking with CAN and CANopen — Copperhill Media, 2008</ref>.
'''Для каждой конкретной сети допускается использование только одного способа контроля или Node Guarding или Heartbeat Protocol.'''

** 5. Изменение объектного словаря. '''''ключевые слова PDO, SDO, PDO-mapping''''' Объектный словарь содержит данные которыми производится обмен по принципу PDO, описывает состав и структуру этих данных. Используя обмен данными по запросу(SDO) можно изменить набор данных которыми будет производиться обмен по принципу PDO. Обмен SDO данными возможен как в состоянии готовности, так и в состоянии работы. Таким образом имеется возможность после включения питания, но до запуска функционирования сети, настроить все приборы сети на обмен нужными данными, а затем запустить сеть. Во время изменения структуры словаря во время работы следует учитывать следующие моменты:
** SDO обмен имеет более низкий приоритет чем обмен PDO, поэтому может возникнуть момент времени, когда часть словаря уже будет изменена в соответствии с новыми требованиями, часть ещё не изменится и в этот момент произойдёт обмен PDO.
** Поскольку устройства передающие и принимающие PDO должны понимать друг друга, то может возникнуть ситуация когда одно устройство будет работать с новой структурой, а другое со старой.
Эти два примера показывают целесообразность изменения структуры словаря только когда сеть остановлена, к сожалению это бывает не всегда возможно.

** 6. Изменение данных по запросу. Помимо изменения словаря приложение одного устройства может загрузить данные в другое устройство. Отличие PDO и SDO обмена данными с точки зрения приложения. При обмене PDO всё происходит автоматически по определённым правилам и приложение не обращаясь к сетевым примитивам получает данные из переменных, как будто бы данные получаются внутри э того самого прибора. Для получения данных по принципу SDO приложение должно при помощи сетевых сервисов запросить данные у другого устройства, и только потом получив ответ использовать данные для работы. Поэтому основу-хребет обмена данными следует строить на PDO-обмене. К сожалению имеются ограничения на размер данных(8 байт для PDO, но можно использовать несколько таких штук). И только при особой необходимости использовать SDO. При SDO обмене данными, устройство к которому обратились с запросом на получение или запись(dowload/upload) данных называется SDO сервером, а устройство которое инициировало обмен называется клиентом. В зависимости от объема передаваемых данных, обмен производится по разным алгоритмам, и может быть не менее эффективен чем PDO обмен. SDO обмен допускает производить контроль безошибочности данных, что позволяет даже загрузку кусков исполняемого кода.

** 7. Авральные объекты, срочные сообщения.'''''Emergency Object, EMCY'''''. В процессе работы прибор может обнаружить ошибки в работе своей программы, или в работе электроники. В таком случае чем скорей об этом будут оповещены все остальные части системы, тем будет лучше и работа такой системы будет безопасней. Для этой цели используются высокоприоритетные срочные сообщения. Такие сообщения посылаются в момент обнаружения неисправности, и в момент исчезновения этой неисправности. Стандарт описывает классы ошибок, такими параметрами могут быть Ток, напряжение, температура. Если в сети задействован механизм срочных сообщений, то устройства обязаны понимать по край мере два сообщения — Общая ошибка(без уточнения категорий), сброс ошибки. Каждый тип ошибки может быть уточнён ещё целым байтом, который может кодировать например номер контролируемой цепочки.

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

Приведённые выше пункты описываются в документах CiA DS-201-207 и CiA DS-301 Разработчик системы «с нуля» может самостоятельно определить функциональные требования к сетке, контролируемые параметры и сценарии поведения при появлении неисправностей. Но поскольку CANopen сети использует большое количество производителей, которые уже разработали системы, охватывающие множество сфер промышленности, то появились рекомендации того, какими параметрами, как минимум, должна оперировать та или иная система, и какие типы реакций на те или иные конкретные ошибки, которые свойственны конкретному классу устройств. Данные рекомендации оформлены в виде стандартов серий CiA DS-4**. Это позволяет производить не системы в целом, а части систем, и эти новые приборы будут прекрасно интегрироваться с системами разработанными именитыми производителями. Часть этих стандартов уже открыты(устоявшиеся), часть остаются достоянием небольших групп производителей(новые, подверженные изменениям). Основная причина того что существует так много закрытых документов та, что это не просто рекомендации, но стандарты при несоблюдении которых нарушается работоспособность системы. При внесении изменений в документы, новые версии рассылаются всем участникам данной группы «по интересам».  Группы по интересам не являются замкнутой кастой, все желающие могут вступить в ту или иную группу. Обязательным условием является денежный взнос. Взимаемые суммы зависят от размера фирмы, и являются демократичными по отношению к малому бизнесу.

<PRE>

РАЗМЕР ФИРМЫ                        ЧЛЕНСКИЙ ВЗНОС(ГОД)     С УЧЁТОМ ГЕРМАНСКИХ НАЛОГОВ   
более чем    100 000   сотрудников: 8 700,00 Euro           10 353,00 Euro                
от 10 000 до 99 999    сотрудников: 5 200,00 Euro           6 188,00  Euro                
от 1 000  до 9 999     сотрудников: 4 100,00 Euro           4 879,00  Euro                
от 100    до 999       сотрудников: 2 100,00 Euro           2 499,00  Euro                
от 50     до 99        сотрудников: 1 500,00 Euro           1 785,00  Euro                
от 10     до 49        сотрудников: 900,00   Euro           1 071,00  Euro                 
от 1      до 9         сотрудников: 650,00   Euro           773,50    Euro                
для школ и университетов          : 520,00 Euro             618,80    Euro                
</PRE>

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

== Промышленные сети семейства CAN ==
* [[CANbus]]
* [[DeviceNet]]

== См. также ==
[[:en:CiA|CiA]]{{ref-en}}.

== Примечания ==
{{примечания}}

== Ссылки ==
*[http://www.can-cia.org/ Официальный сайт организации разрабатывающей и контролирующей данный стандарт - англоязычный, появился маленький уголок на русском, но документы по-прежнему на английском.]
*[http://www.canfestival.org/ CanFestival - кросс-платформенный фреймворк CANopen с открытым исходным кодом]
*[http://www.microcanopen.com/ Онлайн-руководства по CAN и CANopen, объясняющие принципы работы и способы уменьшения затрат на реализацию совместимых драйверов CANopen]
*[http://www.dr-d-morgan.narod.ru/ Документация по технологии CANopen DS.301 на Русском языке ]
*[http://www.datamicro.ru/can_standards_books/  Документы и стандарты DS.2xx/3xx/4xx по CAN и CANopen в pdf формате]
*[http://robot-develop.org/archives/4110  Описание CanOpen на русском языке с примерами на C]

{{Промышленные сети}}

[[Категория:Промышленная автоматика]]
[[Категория:Промышленные сети]]