Журнал РАДИОЛОЦМАН, январь 2013
Михаил Русских
Приводятся основные положения и правила работы протокола CANopen, описываются основные элементы и коммуникационные объекты протокола, поясняются правила организации связи на основе этих объектов.
В наше время насчитывается большое количество интерфейсов последовательной передачи данных. Некоторые из них, например, RS-232, USB, SPI, приобрели огромную популярность благодаря своим характеристикам или простоте использования. Другие же не нашли столь широкого распространения в электронных системах. К ним можно отнести IEEE 1394, RS-449, Х.21. Некоторые стандарты последовательных интерфейсов и вовсе быстро забывались после их разработки, чего нельзя сказать о стандарте CAN (Controller Area Network), разработанном в 1987 году немецкой компанией Robert Bosch GmbH и ставшим, пожалуй, самым популярным интерфейсом последовательной передачи данных в автомобильной отрасли и промышленном оборудовании. Благодаря высокой надежности, довольно высокой скорости передачи данных (до 1 МБ/с) и гибкости настройки и применения, этот интерфейс поддерживается множеством электронных устройств (промышленные контроллеры, микроконтроллеры, специализированные микросхемы, датчики). На сегодняшний день последней версией протокола является CAN 2.0b.
Стандарт CAN описывает поведение сигналов на низком уровне, причем в отрыве от физического уровня, то есть для передачи данных могут использоваться различные среды (медный кабель, оптоволокно и т.п.). Для ускорения проектирования сетей на основе CAN и стандартизации работы таких сетей был разработан протокол высокого уровня CANopen. Он получил широкое распространение в промышленном оборудовании, транспортных средствах, медицинском оборудовании, системах «умный дом». Этот протокол является открытым, и документация по его использованию доступна каждому. DS.301 представляет собой основной документ, в котором описаны основные положения и принципы работы CANopen. В связи с тем, что протокол ориентирован на использование в составе различных классов устройств, в документах CiA DS-4xx регламентируется работа CANopen в каждом из них. Так, например, CiA 412 относится к медицинскому оборудованию, а CiA 417 – к системам управления лифтами.
Топология сети CAN, принципы ее работы и форматы кадров подробно описаны в [1] и [2], поэтому не имеет смысла повторяться, а стоит перейти непосредственно к рассмотрению протокола высокого уровня CANopen на базе данной сети. На Рисунке 1 показана функциональная схема связи двух узлов с помощью шины CAN и протокола CANopen.
 |
|
| Рисунок 1. | Коммуникационные уровни при соединении двух узлов. |
Основной функциональной единицей протокола является объект. Под объектом может пониматься набор данных, несущих информацию о параметрах (например, показания датчика температуры), конфигурации узла или сети, возникших ошибках и т.п. Поэтому для устройства (узла) необходимым условием работы в сети является наличие словаря, представляющего собой группу доступных в определенном порядке объектов. По своей сути, словарь объектов – это связующее звено между приложением и передаваемой на физическом уровне информацией (Рисунок 2). С каждым устройством, использующим интерфейс CANopen, производитель должен предоставить файл с расширением *.eds (Electronic DataSheet), содержащий словарь объектов и дополнительную информацию.
 |
|
| Рисунок 2. | Модель устройства с интерфейсом CANopen. |
CANopen-устройство имеет три условных составляющих: программный модуль обработки протокола и пакетов интерфейса, словарь объектов и программное обеспечение на уровне приложения. Модуль обработки протокола непосредственно отвечает за передачу и прием коммуникационных объектов по шине. Словарь объектов описывает все типы данных, коммуникационные объекты и объекты приложения, используемые в данном устройстве. Программное обеспечение на уровне приложения выполняет функции внутреннего управления и обеспечивает связь с другими устройствами, не использующими шину CAN.
Каждый объект в словаре имеет 16-разрядный индекс и 8-разрядный подиндекс. С помощью них можно ссылаться на данный объект. В Таблице 1 показан пример описания идентификационного объекта, содержащего основную информацию об устройстве.
| Таблица 1. | ||||||||||||||||||||
|
Протокол CANopen предполагает существование следующих типов объектов:
- Сервисные объекты данных (SDO);
- Объекты данных процесса (PDO);
- Специальные функциональные объекты: объект синхронизации (SYNC), временная метка, срочное сообщение (EMCY);
- Объекты управления сетью (NMT): NMT-сообщение, сообщение загрузки (boot-up), объект контроля ошибок.
SDO обеспечивают доступ к элементам словаря объектов, то есть, с помощью SDO можно читать и записывать информацию в словарь объектов. При связи посредством SDO между двумя устройствами устанавливается соединение типа «точка-точка», причем будет реализована клиент-серверная модель коммуникации, где устройство-клиент передает необходимое сообщение, а устройство-сервер выдает соответствующий этому сообщению ответ, в соответствии со схемой, изображенной на Рисунке 3.
 |
|
| Рисунок 3. | Клиент-серверная модель. |
При организации SDO-связи клиент с помощью мультиплексора, содержащего индекс и подиндекс объектного словаря, может предоставлять серверу определенный набор данных, которые будут передаваться. В основном передача SDO реализуется как сегмент-трансферт (segment transfer), при котором передается последовательность сегментов в количестве до 127. Непосредственно до передачи осуществляется стадия подготовки, когда клиент и сервер готовятся к обмену. Если необходимо передать объект размером до 4 байт, такой обмен может быть реализован на стадии инициализации, он также называется ускоренный трансферт (expedited transfer). Существует еще один тип передачи – блок-трансферт (block transfer). При этом передается набор блоков, каждый из которых состоит из 127 сегментов. Один сегмент содержит данные и свой порядковый номер в блоке. SDO описывается параметром связи, определяющим коммуникационные настройки SDO. Эти параметры связи расположены по специально отведенным адресам, и их индексы для SDO-сервера (SSDO) и SDO-клиента (CSDO) вычисляются по следующим правилам:
- Индекс параметра связи SSDO = 1200h + № SSDO – 1;
- Индекс параметра связи CSDO = 1280h + № CSDO – 1.
- Сервисы, реализующие SDO-передачу, могут быть следующими:
- Загрузка на SDO-сервер (download), состоящая из этапа инициализации загрузки и непосредственно загрузки сегментов;
- Выгрузка с SDO-сервера (upload), состоящая из этапа инициализации выгрузки и непосредственно выгрузки сегментов;
- Аварийное завершение передачи SDO.
Для непосредственной передачи полезных данных технологического процесса (температура, скорость, ток, напряжение и т.п.) в реальном времени используются PDO. Передача PDO осуществляется широковещательно, при этом применяется модель производитель-потребитель (producer-consumer), изображенная на Рисунке 4.
 |
|
| Рисунок 4. | Модель производитель-потребитель. |
В объектном словаре различаются два типа PDO – для передачи данных (TPDO) и для приема (RPDO). Устройства, в конкретный момент времени выдающие PDO на шину, называются производителями, а принимающие эти PDO – потребителями. PDO также описываются в объектном словаре устройства. Типы данных и отображение объектов в PDO описываются структурой, называемой PDO-отображение (PDO-mapping). С помощью SDO на стадии инициализации можно изменить количество PDO и отображение объектов внутри них. Все PDO описываются структурным параметром (или параметром отображения) и параметром связи, характеризующим коммуникационные возможности PDO. Индексы этих параметров определяются в соответствии со следующими правилами:
- Индекс параметра связи RPDO = 1400h + № RPDO – 1;
- Индекс параметра связи TPDO = 1800h + № TPDO – 1;
- Индекс структурного параметра RPDO = 1600h + № RPDO – 1;
- Индекс структурного параметра TPDO = 1A00h + № TPDO – 1.
С помощью одного PDO можно передать от 1 до 8 байт данных. В одной сети CANopen может присутствовать до 512 TPDO и до 512 RPDO.
PDO могут передаваться как синхронно, так и асинхронно относительно объекта синхронизации SYNC, выдающегося на шину с определенной периодичностью. Это проиллюстрировано Рисунком 5. Синхронные PDO передаются в рамках установленного интервала времени после появления на шине SYNC-объекта.
 |
|
| Рисунок 5. | Принцип передачи синхронных и асинхронных PDO. |
Асинхронные PDO передаются без какой-либо связи с объектом синхронизации. Различают также три режима вызова PDO (Рисунок 6):
- По событию или по таймеру: механизм передачи PDO запускается после возникновения какого-либо внутреннего события или по срабатыванию таймера устройства;
- По удаленному запросу: в этом случае устройство начинает передачу PDO после получения кадра удаленного запроса от другого устройства на шине;
- Синхронная передача (цикличная или ацикличная): как уже отмечалось ранее, связана с появлением на шине SYNC-объекта.
 |
|
| Рисунок 6. | Три режима вызова PDO. |
Передача синхронных PDO может выполняться как в цикличном режиме, так и ацикличном. При выборе цикличного режима PDO передаются с определенной периодичностью, устанавливаемой числом от 1 до 240, т. е. 5 будет означать передачу PDO после каждого пятого появления SYNC-объекта на шине. В ацикличном режиме момент выдачи PDO на шину определяется внутренним событием устройства, но она обязательно должна выполняться в окне SYNC-объекта.
На Рисунке 7 показан принцип отображения PDO, основная идея которого заключается в том, что как производитель, так и потребитель PDO-сообщения должны знать, каким образом им необходимо интерпретировать содержимое этого сообщения. При этом PDO определяются по их идентификационным номерам (COB-ID). PDO-отображение описывает, какие переменные технологического процесса из поля данных PDO должны передаваться, каким образом они должны быть упорядочены, а также какой тип данных и какую длину они имеют. Таким образом, содержание и значение поля данных каждого определенного PDO определяется в виде записи PDO-отображения внутри словаря объектов на стороне производителя и на стороне потребителя.
 |
|
| Рисунок 7. | Принцип отображения PDO. |
Производитель составляет поле данных передаваемого PDO в соответствии со своими записями отображения TPDO. В связи с этим, текущие значения отсылаемых данных должны быть взяты из словаря объектов и записаны в поле передаваемых данных до того, как сообщение будет отправлено на шину. Подобные операции выполняются на стороне потребителя. В соответствии с записями отображения RPDO, принятые данные записываются в словарь объектов данного устройства.
Другими объектами, без которых немыслимо существование CANopen-сети, являются NMT-объекты, позволяющие управлять работой этой сети. Вначале стоит отметить, что в конкретный момент времени устройство должно находиться в одном из четырех состояний: инициализация (Initialization), готовность (Pre-operational), работа (Operational) или остановка (Stopped). При включении устройство проходит этап внутренней инициализации, и после ее успешного завершения переходит в состояние готовности. В этом состоянии уже возможно осуществить настройку CANopen-узла с помощью SDO. Затем узел может перейти в рабочее состояние. Для этого необходимо, чтобы Master сети (передача NMT сообщений происходит в соответствии с моделью Master-Slave) передал широковещательное сообщение Start_remote_node. ID NMT-сообщений равен 0, поскольку они должны иметь самый высокий приоритет в сети. В Таблице 2 представлено описание NMT-сообщений.
| Таблица 2. | ||||||||||||||||||
|
Формат NMT-сообщения также предполагает наличие ID того узла, которому адресовано сообщение. В случае равенства этого параметра 0 сообщение будет адресовано всем узлам сети, то есть, например, формат 0/1/0 будет означать запуск всех узлов на шине, а 0/2/9 – остановку узла с ID=9.
Для повышения надежности функционирования сети имеются объекты срочных сообщений (Emergency Object или EMCY). Их передача осуществляется при возникновении внутренних ошибок какого-либо узла. Срочное сообщение передается в сеть лишь один раз после возникновения определенной ошибки, и, как бы долго состояние активной ошибки не присутствовало, нового соответствующего ей EMCY передано не будет. Только при возникновении новых ошибок могут быть переданы соответствующие им EMCY. Механизм передачи срочных сообщений не является обязательным для сети CANopen, но при грамотном его применении он позволит вовремя определить и устранить неисправность узла.
Все Slave-устройства в составе сети CANopen могут посылать специальное сообщение о своей готовности функционирования в сети. Это сообщение начальной загрузки (boot-up message) дает понять Master-устройству, что внутренний сетевой статус Slave-узла перешел из режима инициализации в режим готовности к работе. Передача boot-up-сообщения является также необязательной, но желательной процедурой, поскольку Master будет знать, что конкретное Slave-устройство уже можно настраивать с помощью SDO или переводить его в режим работы.
Интерфейсом CANopen предусмотрены два протокола контроля функционирования сети: протокол караула узлов (Node guarding protocol) и протокол контрольного тактирования (Heartbeat protocol). В первом случае выделенный NMT-мастер опрашивает Slave-устройства через одинаковые промежутки времени, называемые guard time. В ответ каждое Slave-устройство посылает сообщение, содержащее его сетевой статус. Время ожидания подобного сообщения может быть настроено индивидуально для каждого узла. Если узел по истечении заданного времени не получил запрос от Master-устройства, на его стороне с помощью сервиса Life Guarding Event возникнет ошибка, свидетельствующая об отсутствии сторожевого запроса. Если удаленный запрос передачи не был подтвержден за время сторожевого ожидания, или указанный в ответном сообщении статус Slave-устройства не соответствует ожидаемому, со стороны Master-устройства возникнет ошибка караула узла, сообщаемая с помощью сервиса Node guarding event.
Heartbeat-протокол позволяет контролировать функционирование сети без необходимости посылки Slave-устройствами удаленных ответов. В данном случае узел, сконфигурированный на широковещательную передачу Heartbeat-сообщения, является производителем контрольных тактов. Остальные устройства, настроенные на прием Heartbeat-сообщения, являются потребителями контрольных тактов, и в случае если за время ожидания контрольного такта (Heartbeat Consumer Time) Heartbeat-сообщение не пришло, генерируется ошибка контрольного тактирования. Оба рассмотренных протокола контроля функционирования сети являются взаимоисключающими, то есть в сети можно использовать лишь один из них. Heartbeat-протокол имеет более высокий приоритет, и по умолчанию предполагается использование именно его.
В данной части были рассмотрены ключевые принципы и правила работы довольно сложного, но в то же время очень надежного протокола CANopen. В следующей части на простом примере будет показана работа CANopen-сети, состоящей из двух узлов.
Список источников
- http://www.piclist.ru/AN-MC-228-RUS/AN-MC-228-RUS.html AN228 - рассмотрение физического уровня CAN.
- Проектирование интеллектуальных датчиков с помощью Microchip dsPIC. Крид Хадлстон – Киев: «МК-Пресс», 2008. – 320 с., ил.
- CANopen. Application Layer and Communication Profile. CiA Draft Standard 301. Version 4.02, 2005. – 135 p.
- CAN словарь. Второе издание. www.can-cia.org.
- CANopen, high-level protocol for CAN-bus. H. Boterenbrood – NIKHEF, Amsterdam, 2000. – 23 p.
- www.canopensolutions.com.
