CANopen

CANopen связи — это стек протоколов и спецификация профиля устройства для встраиваемых систем , используемых в автоматизации . Что касается модели OSI , CANopen реализует вышеперечисленные уровни, включая сетевой уровень . Стандарт CANopen состоит из схемы адресации, нескольких небольших протоколов связи и уровня приложений, определяемого профилем устройства. Протоколы связи поддерживают управление сетью, мониторинг устройств и связь между узлами, включая простой транспортный уровень для сегментации/десегментации сообщений. Протоколом нижнего уровня, реализующим канал передачи данных и физические уровни, обычно является сеть контроллеров (CAN), хотя устройства, использующие некоторые другие средства связи (например, Ethernet Powerlink , EtherCAT ), также могут реализовывать профиль устройства CANopen.

Базовые профили устройств CANopen и связи приведены в спецификации CiA 301, выпущенной CAN in Automation . ^[1] Профили для более специализированных устройств создаются на основе этого базового профиля и указаны во многих других стандартах, выпущенных CAN в автоматизации, таких как CiA 401. ^[2] для модулей ввода/вывода и CiA 402 ^[3] для управления движением.

Модель устройства

Каждое устройство CANopen должно реализовывать определенные стандартные функции в своем управляющем программном обеспечении.

• Блок связи реализует протоколы обмена сообщениями с другими узлами сети.
• Запуск и сброс устройства контролируются через конечный автомат . Он должен содержать состояния «Инициализация», «Предоперационный», «Рабочий» и «Остановлен». Переходы между состояниями выполняются путем выдачи устройству объекта связи управления сетью (NMT).
• Словарь объектов представляет собой массив переменных с 16-битным индексом. Кроме того, каждая переменная может иметь 8-битный субиндекс. Переменные могут использоваться для настройки устройства и отражать его среду, т.е. содержать данные измерений.
• Прикладная . часть устройства фактически выполняет желаемую функцию устройства после того, как конечный автомат переведен в рабочее состояние Приложение настраивается с помощью переменных в словаре объектов, а данные отправляются и принимаются через уровень связи.

Словарь объектов

Устройства CANopen должны иметь словарь объектов, который используется для настройки и связи с устройством. Запись в словаре объектов определяется:

• Индекс , 16-битный адрес объекта в словаре.
• Имя объекта (тип/размер объекта), символический тип объекта в записи, например массив, запись или простая переменная.
• Имя — строка, описывающая запись.
• Type указывает тип данных переменной (или тип данных всех переменных массива).
• Атрибут , который предоставляет информацию о правах доступа к этой записи. Это может быть чтение/запись, только чтение или только запись.
• Поле Обязательное/Необязательное (M/O) определяет, должно ли устройство, соответствующее спецификации устройства, реализовывать этот объект или нет.

Базовые типы данных для значений объектного словаря, такие как логические значения , целые числа и числа с плавающей запятой, определены в стандарте (их размер в битах опционально сохраняется в определении связанного типа, диапазон индексов 0x0001–0x001F), а также составные типы данных, такие как строки, массивы. и записи (определенные в диапазоне индексов 0x0040–0x025F). Составные типы данных могут быть субиндексированы с помощью 8-битного индекса; значение субиндекса 0 массива или записи указывает количество элементов в структуре данных и имеет тип UNSIGNED8.

Например, параметры связи устройства, стандартизированные в базовом профиле устройства CiA 301. ^[4] отображаются в диапазоне индексов 0x1000–0x1FFF («область профиля связи»). Первые несколько записей в этой области следующие:

Индекс	Имя объекта	Имя	Тип	Атрибут	М/О
0x1000	БЫЛ	тип устройства	БЕЗПИСЬМО32	ро	М
0x1001	БЫЛ	регистр ошибок	БЕЗПИСАННЫЙ8	ро	М
...
0x1008	БЫЛ	название устройства производителя	Вис-Строка	константа	ТО
...

При наличии подходящих инструментов содержимое объектного словаря устройства, основанного на электронном паспорте данных (EDS), можно преобразовать в файл конфигурации устройства (DCF) для интеграции устройства в конкретную сеть CANopen. Согласно CiA 306 ^[5] , формат файла EDS — это формат файла INI . В будущем появится формат XML, описанный в CiA 311. ^[6] .

Коммуникация

Объекты связи

Шина CAN , уровень канала передачи данных CANopen, может передавать только короткие пакеты, состоящие из 11-битного идентификатора, бита запроса удаленной передачи (RTR) и от 0 до 8 байтов данных. Стандарт CANopen разделяет 11-битный идентификатор кадра CAN на 4-битный код функции и 7-битный идентификатор узла CANopen. Это ограничивает количество устройств в сети CANopen до 127 (0 зарезервировано для широковещательной передачи). Расширение стандарта шины CAN (CAN 2.0 B) позволяет использовать расширенные идентификаторы кадров до 29 бит, но на практике сети CANopen, достаточно большие, чтобы нуждаться в расширенном диапазоне идентификаторов, встречаются редко.

В CANopen 11-битный идентификатор CAN-кадра известен как идентификатор объекта связи или COB-ID. В случае конфликта при передаче арбитраж шины, используемый в шине CAN, позволяет передать кадр с наименьшим идентификатором первым и без задержки. Использование низкого кода для функций, критичных ко времени, обеспечивает минимально возможную задержку.

Содержимое кадра CANopen:

	CAN-ID	РТР	Длина данных	Данные
Длина	11 бит	1 бит	4 бита	0–8 байт

Кадр данных с 11-битным идентификатором также называется «форматом базового кадра».

Сопоставление CAN-ID по умолчанию сортирует кадры путем присвоения кода функции (NMT, SYNC, EMCY, PDO, SDO...) первым 4 битам, так что критическим функциям отдается приоритет. Однако это сопоставление можно настроить для специальных целей (за исключением NMT и SDO, необходимых для базовой связи).

	Код функции	Идентификатор узла
Длина	4 бита	7 бит

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

Предопределенный набор соединений ^[7]

Для простых сетевых структур CANopen поддерживает заранее определенное распределение идентификаторов сообщений.

Направления передачи и приема указаны с точки зрения устройства. Таким образом, запрос к устройству в сети отправит 0x600+nodeid и вернет 0x580+nodeid.

Объект связи	COB-ID(а) шестнадцатеричный	Подчиненные узлы	Спецификация
Управление узлом NMT	000	Получать только	СиА 301
Глобальная команда отказоустойчивости	001	?	CiA 304
Летающий мастер	с 071 по 076	?	СиА 302-2
Указать активный интерфейс	07F	?	СиА 302-6
Синхронизировать	080	Получать только	СиА 301
Чрезвычайная ситуация	080 + идентификатор узла	Передача	СиА 301
Временная метка	100	Получать только	СиА 301
Объекты данных, важные для безопасности	от 101 до 180	?	СиА 301
ПДО	180 + идентификатор узла 200 + идентификатор узла 280 + идентификатор узла 300 + идентификатор узла 380 + идентификатор узла 400 + идентификатор узла 480 + идентификатор узла 500 + идентификатор узла	1. Передача PDO 1. Получить PDO 2. Передача PDO 2. Получить PDO 3. Передача PDO 3. Получить PDO 4. Передача PDO 4. Получить PDO	СиА 301
СДО	580 + идентификатор узла 600 + идентификатор узла	Передача Получать	СиА 301
Динамический запрос SDO	6E0	?	CiA 302-5
Процедура заявки на узел	от 6E1 до 6E3	?	CiA 416-1
Процедура заявки на узел	от 6F0 до 6FF	?	CiA 416-1
Мониторинг узла NMT (защита узла/контрольное состояние)	700 + идентификатор узла	Передача	СиА 301
СЖО	7Е4 7E5	Передача Получать	ЦиА 305

Коммуникационные модели

При обмене сообщениями между узлами CANopen используются различные виды моделей связи.

В отношениях главный/подчиненный один узел CANopen назначается главным, который отправляет или запрашивает данные от подчиненных устройств. Протокол NMT является примером модели связи «ведущий/подчиненный».

Отношения клиент/сервер реализованы в протоколе SDO, где клиент SDO отправляет данные (индекс и субиндекс объектного словаря) на сервер SDO, который отвечает одним или несколькими пакетами SDO, содержащими запрошенные данные (содержимое объектного словаря). по данному индексу).

Модель производитель/потребитель используется в протоколах Heartbeat и Node Guarding. В модели push- производитель/потребитель производитель отправляет данные потребителю без конкретного запроса, тогда как в модели pull потребитель должен запрашивать данные у производителя.

Протоколы

Протоколы сетевого управления (NMT)

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

Протокол управления модулем используется мастером NMT для изменения состояния устройств. COB-ID CAN-кадра этого протокола всегда равен 0, что означает, что он имеет код функции 0 и идентификатор узла 0, что означает, что каждый узел в сети будет обрабатывать это сообщение. Фактический идентификатор узла, которому предназначена команда, указывается в части данных сообщения (во втором байте). Это также может быть 0, что означает, что все устройства на шине должны перейти в указанное состояние.

COB-ID	Байт данных 0	Байт данных 1
0x000	Запрошенное состояние	Адресуемый узел

Код команды NMT	Значение
0x01	Перейти в «оперативный»
0x02	Перейти к «остановлено»
0x80	Перейти к «предоперационной подготовке»
0x81	Перейдите к «сбросить узел»
0x82	Перейти к «сбросить связь»

Протокол Heartbeat используется для мониторинга узлов в сети и проверки их работоспособности. Производитель контрольных сигналов (обычно ведомое устройство) периодически отправляет сообщение с двоичным кодом функции 1110 и идентификатором своего узла (COB-ID19 = 0x700 + идентификатор узла). Часть данных кадра содержит байт, указывающий состояние узла. Потребитель Heartbeat читает эти сообщения. Если сообщения не доставляются в течение определенного срока (определенного в объектном словаре устройств), потребитель может предпринять действия, например, перезагрузить устройство или указать на ошибку.Формат кадра:

COB-ID	Байт данных 0
0x700 + идентификатор узла	Состояние

Государственный код НМТ	Представленное государство
0x00	Загрузка (инициализация)
0x04	Остановлено
0x05	Оперативный
0x7f	Предэксплуатационный

Устройства CANopen должны автоматически переходить из состояния инициализации в состояние подготовки к работе во время загрузки. При выполнении этого перехода на шину отправляется одно контрольное сообщение. Это протокол загрузки .

Для мониторинга подчиненных устройств существует протокол типа «ответ/ответ» (модель извлечения), называемый защитой узла.

Протокол объекта служебных данных (SDO)

Не путать с объектами сервисных данных — абстракцией данных как услуги.

Протокол SDO используется для установки и чтения значений из объектного словаря удаленного устройства. Устройство, к словарю объектов которого осуществляется доступ, является сервером SDO, а устройство, обращающееся к удаленному устройству, является клиентом SDO. Связь всегда инициируется клиентом SDO. В терминологии CANopen связь рассматривается с сервера SDO, так что чтение из словаря объектов приводит к загрузке SDO, а запись в запись словаря — к загрузке SDO.

Поскольку значения объектного словаря могут превышать восьмибайтовый предел кадра CAN, протокол SDO реализует сегментацию и десегментацию более длинных сообщений. На самом деле существует два таких протокола: загрузка/выгрузка SDO и загрузка/выгрузка блоков SDO. Блочная передача SDO — это новое дополнение к стандарту, которое позволяет передавать большие объемы данных с немного меньшими издержками протокола.

COB-ID соответствующих сообщений передачи SDO от клиента к серверу и от сервера к клиенту могут быть установлены в словаре объектов. В словаре объектов по адресам 0x1200–0x127F можно настроить до 128 SDO-серверов. Аналогично, клиентские подключения SDO устройства можно настроить с помощью переменных 0x1280–0x12FF. Однако предварительно определенный набор соединений определяет канал SDO, который можно использовать даже сразу после загрузки (в предоперационном состоянии) для настройки устройства. COB-ID этого канала: 0x600 + идентификатор узла для приема и 0x580 + идентификатор узла для передачи.

Чтобы инициировать загрузку, клиент SDO отправляет следующие данные в сообщении CAN с «приемным» COB-ID канала SDO.

Номер обмена:	Байт 0					Байт 1-2	Байт 3	Байты 4–7
Длина:	3 бита	1 бит	2 бита	1 бит	1 бит	2 байта	1 байт	4 байта
Значение:	ccs=1	зарезервировано(=0)	н	и	с	индекс	субиндекс	данные

• ccs — это спецификатор клиентской команды для передачи SDO, это 0 для загрузки сегмента SDO, 1 для инициации загрузки, 2 для инициации загрузки, 3 для загрузки сегмента SDO, 4 для прерывания передачи SDO, 5 для загрузки блока SDO и 6 для Загрузка блока SDO
• n — количество байтов в части данных сообщения, которая не содержит данных, допустимо только в том случае, если установлены e и s.
• e , если установлено, указывает на ускоренную передачу, т. е. все обмениваемые данные содержатся в сообщении. Если этот бит сброшен, сообщение представляет собой сегментированную передачу, при которой данные не помещаются в одно сообщение и используются несколько сообщений.
• s , если установлен, указывает, что размер данных указан в n (если установлен e) или в части данных сообщения.
• индекс — это индекс объектного словаря данных, к которым осуществляется доступ, закодированный с прямым порядком байтов.
• субиндекс — это субиндекс переменной объектного словаря.
• data содержит данные, подлежащие загрузке в случае ускоренной передачи (установлен e), или размер загружаемых данных (установлен s, e не установлен), часто закодированный с прямым порядком байтов

Протокол объекта данных процесса (PDO)

Протокол Process Data Object используется для обработки данных в реальном времени между различными узлами. Вы можете передавать до 8 байтов (64 бита) данных на один PDO как с устройства, так и на него. Один PDO может содержать несколько записей словаря объектов, а объекты внутри одного PDO настраиваются с помощью записей словаря объектов сопоставления и параметров.

Существует два типа PDO: PDO передачи и приема (TPDO и RPDO). Первый предназначен для данных, поступающих с устройства (устройство является производителем данных), а второй — для данных, поступающих на устройство (устройство является потребителем данных); то есть с помощью RPDO вы можете отправлять данные на устройство, а с помощью TPDO вы можете считывать данные с устройства. В предопределенном наборе соединений доступны идентификаторы для четырех TPDO и четырех RPDO. При настройке возможно 512 PDO.

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

С помощью RPDO вы можете, например, запускать два устройства одновременно. Вам нужно всего лишь сопоставить один и тот же RPDO с двумя или более разными устройствами и убедиться, что эти RPDO сопоставлены с одним и тем же COB-ID.

Протокол объекта синхронизации (SYNC)

Sync-Producer предоставляет сигнал синхронизации для Sync-Consumer. Когда Sync-Consumer получает сигнал, он начинает выполнять свои синхронные задачи.

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

Идентификатор объекта синхронизации доступен по индексу 1005h.

Протокол объекта метки времени (TIME)

Обычно объект Time-Stamp представляет время в виде 6-байтового поля: количество миллисекунд после полуночи (не более 27 бит, хранящихся в 32-битном поле) и беззнаковое 16-битное количество дней с 1 января. 1984 г. (Это произойдет 7 июня 2163 г.).

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

Метка времени высокого разрешения кодируется как unsigned32 с разрешением 1 микросекунда, что означает, что счетчик времени перезапускается каждые 72 минуты. Он настраивается путем сопоставления метки времени высокого разрешения (объект 1013h) с PDO.

Протокол аварийного объекта (EMCY)

Экстренные сообщения инициируются при возникновении ситуации внутренней фатальной ошибки устройства и передаются от соответствующего прикладного устройства к другим устройствам с высоким приоритетом. Это делает их подходящими для предупреждений об ошибках типа прерывания. Экстренная телеграмма может быть отправлена ​​только один раз за «событие ошибки», т.е. экстренные сообщения не должны повторяться. Пока на устройстве не возникло новых ошибок, дальнейшее экстренное сообщение отправляться не должно.С помощью профиля связи CANopen определяются коды аварийных ошибок, регистр ошибок и дополнительная информация, специфичная для устройства, указываются в профилях устройства.

Инициализация

Пример трассировки связи между главным устройством и двумя подчиненными датчиками давления, настроенными для идентификатора 1 и идентификатора узла 2.

CAN-идентификатор	ДЛИНА ДАННЫХ	ДАННЫЕ	Описание
0x0	2	01 00	Мастер переводит все устройства на шине в рабочий режим.
0x80	0		Мастер отправляет сообщение SYNC, которое заставляет устройства отправлять данные.
0x181	4	CD 82 01 00	Узел с идентификатором 1 (CID-0x180), считывание давления 0x0182CD (99021) паскалей.
0x182	4	Е5 83 01 00	Узел с идентификатором 2 (CID-0x180), считывание давления 0x0183E5 (99301) паскалей.

Электронный паспорт

Электронный лист данных (EDS) — это формат файла, определенный в CiA306, который описывает поведение связи и записи объектного словаря устройства. Это позволяет таким инструментам, как сервисные инструменты, инструменты настройки, инструменты разработки и другие, правильно обрабатывать устройства.

Эти файлы EDS являются обязательными для прохождения теста на соответствие CiA CANopen.

новый формат на основе XML С конца 2007 года в CiA311 определен , называемый XDD. XDD соответствует стандарту ISO 15745.

Глоссарий терминов CANopen

• PDO : Объект данных процесса — входы и выходы. Значения типа скорости вращения, напряжения, частоты, электрического тока и т. д.
• SDO : Объект служебных данных — настройки конфигурации, возможно, идентификатор узла, скорость передачи данных, смещение, усиление и т. д.
• COB-ID : идентификатор объекта связи.
• CAN ID : CAN-идентификатор. Это 11-битный идентификатор сообщения CAN, который находится в начале каждого сообщения CAN на шине.
• ЭЦП : Электронный паспорт. Это файл в формате INI или XML.
• DCF : файл конфигурации устройства. Это модифицированный файл EDS с настройками идентификатора узла и скорости передачи данных.

См. также

• Контроллерная сеть — это статья на CAN-шине.
• J1939
• Девайснет
• ИЭЭЭ 1451
• ПреобразовательML

Ссылки

1. ^ Спецификация прикладного уровня CiA 301 CANopen, которую можно бесплатно загрузить с сайта CAN in Automation.
2. ^ Спецификация электронного паспорта данных (EDS) CiA 306 CANopen
3. ^ CiA 311 Спецификация CANopen XML-EDS
4. ^ Предопределенный набор соединений из Основ CANopen [8]
5. ^ Спецификация профиля устройства CiA 401 CANopen для универсальных модулей ввода-вывода, которую можно бесплатно загрузить с сайта CAN в автоматизации.
6. ^ Профиль устройства CiA 402 CANopen для контроллеров движения и приводов (аналогично IEC 61800-7-201/301)

Внешние ссылки

• CANopen Origins — проект Esprit ASPIC 1993 (Bosch, Университет Ньюкасла, Университет прикладных наук в Ройтлингене)
• О CANopen (canopensolutions.com)
• Использование идентификатора в сетях CANopen
• CanFestival — многоплатформенная платформа CANopen с открытым исходным кодом.
• CanOpenNode — платформа CANopen с открытым исходным кодом для микроконтроллеров и Linux.
• Lely CANopen — библиотека CANopen с открытым исходным кодом для ведущих и ведомых устройств.
• openCANopen — мастер CANopen с открытым исходным кодом.
• Проект CANopen Stack — гибкий стек CANopen с открытым исходным кодом для микроконтроллера.
• CANopen для Python
• CANnewsletter-Информация о CAN, CANopen и J1939
• Образовательные страницы CANopen
• Введение в основы CANopen (на сайте www.canopen-solutions.com)
• Wiki сообщества CANopen-Lift
• CANeds: бесплатный редактор файлов EDA и XDD.
• Интернет-портал CAN в автоматизации
• CANopen — прикладной уровень и общий профиль связи